Jesse I Pollard wrote:
[EMAIL PROTECTED] wrote:
So would it be possible to export unions over NFS4 if we initialized
sb->s_export_op in unionfs_read_super(), along the lines of what was
done in unionfs-1.4 ?
Does anyone have a patch which does that ? I do not mind if it only
supports lower filesystems with small inode numbers or if branches
cannot be added/removed afterward.
nope. been there, tried that.
Thanks for the feedback... But did you discover that there are
fundamental incompatibilities, or only that it did not work as
easily as expected ?
From RFC3530 (NFS version 4):
> 4.2. Filehandle Types
> The volatile filehandle type was introduced to address server
> functionality or implementation issues which make correct
> implementation of a persistent filehandle infeasible. Some server
> environments do not provide a filesystem level invariant that can be
> used to construct a persistent filehandle.
> 4.2.3. Volatile Filehandle
> FH4_VOLATILE_ANY
> The filehandle may expire at any time, except as
> specifically excluded (i.e., FH4_NO_EXPIRE_WITH_OPEN).
> FH4_NOEXPIRE_WITH_OPEN
> May only be set when FH4_VOLATILE_ANY is set. If this bit
> is set, then the meaning of FH4_VOLATILE_ANY is qualified
> to exclude any expiration of the filehandle when it is
> open.
> 4.3. Client Recovery from Filehandle Expiration
> For volatile filehandles, most commonly the client will need to store
> the component names leading up to and including the filesystem object
> in question. With these names, the client should be able to recover
> by finding a filehandle in the name space that is still available or
> by starting at the root of the server's filesystem name space.
With all this, shouldn't we be able to export dynamically-allocated inode
numbers, and declare them expired when they leave the unionfs cache ?
Unfortunately I suspect volatile filehandles are not supported yet in the
current Linux NFS4 implementation (i.e. "grep NFS4_FH_VOL fs/nfs*/*"
does not find much).
Pascal
_______________________________________________
unionfs mailing list: http://unionfs.filesystems.org/
unionfs@mail.fsl.cs.sunysb.edu
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
