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@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. I think then there's no limit to the lifetime of those log entries, or to the size of the log? --b. > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
