Re: [PATCH/RFC 0/7] Volatile Filehandle Client-side Support

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 2570 bytes --]

On Sun, 13 Nov 2011 19:42:54 -0500 "J. Bruce Fields" <bfields@fieldses.org>
wrote:

> On Mon, Nov 14, 2011 at 08:07:45AM +1100, NeilBrown wrote:
> > On Sun, 13 Nov 2011 11:36:32 -0500 "J. Bruce Fields" <bfields@fieldses.org>
> > 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.
> 
> I think then there's no limit to the lifetime of those log entries, or
> to the size of the log?

The lifetime of the log entry matches the lifetime of an 'open', just like
any state that the server holds on behalf of a client.  They can be discarded
on last close, or when you haven't heard from the client for the lease-time.

The size of the log is bounded by the maximum number of allowed clients, and
the maximum number of concurrent opens per client.  i.e. it is the same order
and the amount of open state that the server needs to store at any one time.

So the only really 'new' thing here is that more of the state needs to be on
stable storage - it isn't really substantially more state.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]