Re: [9fans] p9p vac/vacfs compatibility: uid/gid, ctime, 9P2000.L, 9pserve

[David du Colombier <0intro@gmail.com>]

> OK, I'm stumped.  Maybe I'm making this more complicated than it has
> to be.  Posing my question as simply as possible: If plan9port's vac
> is used to archive a Linux file system to venti, is there any way to
> access that file system in a way that exposes symbolic links, device
> nodes, sockets, and FIFOs in the archive?

The Vac file system does already handle some foreign file system
properties, but not everything.

If you don't want to change the Vac file system format, you'd
probably better use vbackup(8) to store an Unix file system
directly on Venti.

> (1) When using Linux's v9fs to mount a file system served by
> plan9port's vacfs, the symlinks and device nodes all stat as regular
> files.  The file size of symlinks reflects the length of the link
> target, and the device files have a size of 3 bytes (for type, major,
> and minor).  This happens whether or not I include version=9p2000.u
> or 9p2000.L as mount options.

That's fine, because for both DMSYMLINK and DMDEVICE, the required
information (respectively target and type/major/minor) is written
in the data block.

Using 9p2000.u or 9p2000.l is not likely to change anything, since
vacfs and 9pserve only serve 9P2000 anyway.

> When I use 9pfuse to mount the file system, I get a little further:
>
> lrw-rw---- 1 root root        6 Mar 10  2005 video ->
> -rw-rw---- 1 root root        3 Mar 10  2005 video10
>
> The symbolic links show up as links, but with the null string ("") as
> target.  The Linux kernel interperets null symlinks to mean "./",
> causing all the links to refer to the directory in which they
> reside. :( The device files still present as ordinary files with a
> size of 3 bytes. Running "readlink" on the symbolic links always
> returns the null string.

I'm still not sure where the problem is.

V9fs only seems to display file and directory modes. 9pfuse seems
to display symlink too. But neither of two seems to correctly
interpret the special files from their mode and data.

The vac code looks correct. I just found a bug in the handling of
DMSYMLINK and DMDEVICE, but it's not directly related to your problem.

> (2) plan9port's unvac explicitly skips extraction of files which are
> not regular files or directories.  So, unvac-ing the archive isn't
> possible, either.  :(

Unvac is a special case because it extracts files from a file system to
another file system. But some properties may not be settable on
the target file system. Unvac is rather safe concerning the files it
extracts and the properties it sets. Fell free to change its behavior.

> (4) The 9p utility provided by plan9port gets me access to a little
> more metadata.  Using the 9p "ls" command:
>
> -Lrwxrwxrwx M 0 root root 5 Jan  2 03:16 modem
> D-rw-rw---- M 0 root disk           3 Mar 10  2005 hda
>
> You can see the symlink and device bits set in the mode.  (The "D"
> represents a device node; "d" indicates a directory.)

The mode itself is just a 32-bit integer and is perfectly handled by
both Vac and 9P.

> Using the 9p "stat" command:
>
> 'modem' 'root' 'root' '' q (0000000000000003 0 ) m 0200000777 at
> 1325474216 mt 1325474215 l 5 t 0 d 0
> 'tty3' 'root' 'tty' '' q (0000000000001528 0 ) m 040000660 at
> 1110476900 mt 1110476900 l 3 t 0 d 0
>
> The targets of symlinks are still showing up as the null string.  (I'm
> assuming that's what the '' represents.)

No, this is the mid, which is not handled on Unix file systems.
The 9P stat format is described in stat(9p).

The symlink target is in the data blocks.

> (5) Installing Inferno just to access vac'd Linux file systems would
> really be tantamount to throwing up my hands and giving up on
> plan9port. I'd like use plan9port, if possible, rather than have to
> layer a whole new OS on top of Linux+p9p.

I can't see how Inferno could help you. The Inferno vacfs doesn't
even handle any Unix file system property.

--
David du Colombier