HAMMER and NFS?
dillon at apollo.backplane.com
Fri Jul 18 19:19:23 PDT 2008
:Do you have some known limitation(or bugs) related to NFS-exporting of
:HAMMER filesystem? I've been playing with /etc/exports so as I can
:upgrade my router to 2.0, and found something strange:
:- can't NFS-mount an exported directory inside a HAMMER filesystem,
: only root directory can be NFS-mounted (no errors from mountd though)
This should work. Does your /etc/exports line include -alldirs ?
:- can't NFS-mount an exported pseudofs (Permission denied), or
: NFS-mount a pseudofs inside an exported HAMMER filesystem
: (again, no errors from mountd)
:- I can mount it read-only, but accessing a pfs gives me `File too large'
: that is:
Both of these are the same problem. Definitely a bug... I think it's
just that I am not storing the correct value for the st_size field of
the PFS softlink. PFS softlinks are special, HAMMER expands them in
place to a full transaction id + PFS format. So the readlink()
returns a string with a different size then stat shows in st_size.
NFS is probably depending on st_size being correct.
However there is a secondary issue here which you have to be aware
of. Once I do fix this, exporting PFS SLAVES will still require -alldirs
and it also means that whenever someone does a mount of a slave, they
will actually be mounting a snapshot. That snapshot is just that, a
snapshot. If the slave is updated, the mount will still depict the
snapshot as of the original mount. The NFS client will have to umount
and re-mount that NFS mount to sync with the latest snapshot. There is
no way around that, the snapshot transaction id is actually part of
the file-handle structure NFS uses to keep track of the mount.
: lrwxr-xr-x 1 root wheel 3 Jul 19 09:36 /mnt/symlink -> foo
: # ls -dlL /mnt/symlink
: drwxr-xr-x 1 root wheel 0 Jul 19 09:35 /mnt/symlink
: # umount /mnt
: # mount 127.0.0.1:/HAMMER /mnt
: # ls -l /mnt
: total 0
: drwxr-xr-x 1 root wheel 0 Jul 19 09:35 foo
: ls: /mnt/obj: File too large
: lrwxr-xr-x 1 root wheel 10 Jul 18 12:31 obj
: lrwxr-xr-x 1 root wheel 3 Jul 19 09:36 symlink -> foo
Ok, I know what this is. The mtime of the directory is not being
updated by file/link creation, so NFS does not know that it must throw
away its directory cache. I'll fix this tonight too.
<dillon at backplane.com>
More information about the Kernel