On Sun, 13 Nov 2011 11:36:32 -0500 "J. Bruce Fields" <bfields@xxxxxxxxxxxx>
wrote:
> On Sun, Nov 13, 2011 at 02:45:48PM +0100, Tigran Mkrtchyan wrote:
> > I have a server which runs on top of hadoop. The problem with hadoop
> > is that there is no way to have persistent file handles. I am
> > currently working on a way to do that - either simulate them or add a
> > support for unique file id to hadoop. If linux client will support
> > volatile file handles then I can stop inventing some workarounds.
>
> I might call that "fixing" rather than inventing workarounds.
>
> Our of curiosity: if we really wanted to support such filesystems, what
> would we need in the protocol? Just saying "filehandles aren't stable,
> deal with it" seems insufficient.
1/ no guarantees if the file is not 'open'
2/ two possible responses to FHEXPIRED:
a/ perform a GETATTR and request the 'filehandle' attribute. Client then
uses that filehandle instead.
b/ perform LOOKUP on parent filehandle with same name as before, and use
the resulting filehandle.
Server specifies which somehow (different error code? magic attribute
flag somewhere? doesn't really matter)
If a server has objects that are never renamed, it can easily use volatile
file handles.
If a server has objects which can be renamed and wants to use volatile file
handles, then if such an object is open and is about to be renamed, it must
first log to stable storage some mapping to allow it to access the file from
the old volatile file handle. And of course it cannot allow renames during
the grace period, but I think we already have that.
Also, if the VFH is such that it will be lost on a reboot, the server must
log it to stable storage before allowing an open.
>
> Say there was some way for the client to indicate which filehandles it
> currently has in use, and some way for the server to ask the client to
> return in-use filehandles if there are too many (like DELEG_RECALL_ANY).
> Then the server could at least place a limit on the number of
> filehandles that it had to guarantee persistent.
>
> And/or the client could get a callback on rename/link/unlink. Bah.
>
> Would any of that actually be easier than implementing persistent file
> handles?
Easier for whom? Should NFSv4 be designed to make life easier for filesystem
implementers, or easier for NFS implementers :-?
While I don't have concrete examples I would not be surprised if there were
filesystems where implementing limited persistence was practical while
implementing universal persistence was not.
NeilBrown
Attachment:
signature.asc
Description: PGP signature
