[Lustre-devel] Re: fixing redundant network opens on Linux file creation

[Andreas Dilger]

On Jan 07, 2003  09:28 -0800, Bryan Henderson wrote:
> >JFS, VxFS and
> >NetApp seem to use "intent logging" to mean something similar ("I will
> >be doing this next", rather than "I might be doing this next, but maybe
> >not").  Maybe I misunderstand the intent log, though, and the time at
> >which it gets updated.  It certainly does seem to describe fact rather
> >than a fallible expectation.
> 
> I'm not a big fan of this use of the word "intent" either, and in fact the
> technique it refers to is often called other things.  But it definitely
> _is_ a case where the intent can be abandonned.  That's the whole point --
> you log an intent to create a file, but don't actually commit to creating
> it.  If the system should crash before all the corequesisites of that
> creation are complete, the file ends up never having been created.  In
> contrst, the proposed Linux lookup-with-intent scheme appears actually to
> irrevocably create a file as soon as the "intent" to create it is declared.

I don't see where you are coming from here.  Could you be more specific on
whether you think the entity declaring an "intent" is user-space, the VFS
code in fs/*.c, the filesystem driver code in fs/*/*.c or what?  I don't
really see where you can "change your mind" in the middle of creating a
file, unless there was an error somewhere along the way.  If you call
sys_mkdir() you have declared an "intent" to create a directory, and the
VFS better not arbitrarily decide that it doesn't feel like creating
directories today.

What I am getting at, is that once an application has called a system call,
either that system call will do what it was supposed to do (e.g. create,
rename, remove, change a file/dir) or it will have an error.  Whether that
operation was done in the "lookup-with-intent call on server + op fixup on
client" or as a lookup+op call on a local filesystem is unrelated to the
fact that the operation will complete either way.

The "intent" that we are talking about in regards to Lustre is not a "maybe"
thing like open(..., O_RDWR) where you may or may not read or write to a
file after opening it.  The intent is set up at entry to the kernel syscall
code, and is destroyed before the syscall returns to user code again.  The
only two options are that the server acted on the intent and did the operation
there and the kernel code on the client handles this, or the server granted
a lock to the client, and the kernel code on the client is required to
complete the operation itself.  Anything else is a bug.

> Note that in theory, the invoker of the VFS protocol operations could be
> anything, and the filesystem driver should not care.  Even in practice, it
> is not always the 'fs/' component.  Sometimes it is the NFS server code.

Or, by no small coincidence, the Lustre target code.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/