DragonFly kernel List (threaded) for 2008-07
DragonFly BSD
DragonFly kernel List (threaded) for 2008-07
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: HAMMER and NFS?


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Fri, 18 Jul 2008 19:16:20 -0700 (PDT)

:Hi.
: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
:
: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!

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]