HAMMER and NFS?

YONETANI Tomokazu qhwt+dfly at les.ath.cx
Sat Jul 19 00:36:22 PDT 2008


On Fri, Jul 18, 2008 at 07:16:20PM -0700, Matthew Dillon wrote:
> :- 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 ?

That and restarting nfsd+mountd did the trick it seems.  My fstab contained
'noauto' keyword, so by the time the NFS daemons started they didn't know
about the subdirectories inside HAMMER filesystem and just sending SIGHUP
to mountd didn't make subdirectories mountable.
 
> :- 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.

That's fine by me, but having it noted in hammer(5) would be better probably.

> :  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
> :
> :Thanks.
> 
>     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.
> 
>     Nice catches!

I confirmed that all of the problems above are fixed now!
Thanks.





More information about the Kernel mailing list