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

[Peter Braam <braam@clusterfs.com>]

Hi, 

I have no objections to a name change.  We are not so religious about
"intent" as a name.

On Wed, Jan 08, 2003 at 10:52:51AM -0700, Bryan Henderson wrote:

> >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?
> 
> As a general principle, any of those things could declare intent.  In the
> Lustre design we're talking about, I don't believe any of them does.  Hence
> my objection to the term "intent."  Based on that word, I thought at first
> I might just have missed something in the definition of the interface, but
> I don't think so anymore.
> 
> >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.

open with O_CREATE | O_EXCL is a good example.

> I don't either.  (And apparently, simple errors are no exception in the
> Lustre design).  Hence, you have declared significantly more than an intent
> when you did the lookup.
> 
> >If you call
> >sys_mkdir() you have declared an "intent" to create a directory
> 
> Not as "intent" is usually understood.  If you call sys_mkdir(), you have
> commanded the kernel to create the directory.  That's a lot different from
> declaring that you intend to create the directory.
> 
> I believe the lustre patch works.  I also believe it uses the wrong
> terminology, creates an interface to filesystem drivers that is brittle and
> hard to understand, and doesn't solve as wide a range of problems as it
> could.  I believe that what it calls a declaration of intent is really a
> declaration of what POSIX system call the caller is in the middle of
> performing.
> 
> On the other hand, it has been pointed out that one of its goals was to
> minimize the changes to fs/*.c.  I agree the patch is a good way to achieve
> that goal.
> 
> If it were my decision, I would solve the Lustre problem, and the Samba
> problem, and some of my own as well, by putting higher level filesystem
> driver interfaces into Linux, such as some other kernels do. 
>
>  Let the
> filesystem driver do the whole "lookup, create directory, add directory
> entry" operation if it wants to, and in that case make just that one call
> to the filesystem driver and be done.  Let the filesystem driver deal with
> the problems of failures halfway through the sequence.
> 
> But suggestions I've made to give more power to filesystem drivers have in
> the past met resistance from those who want to keep centralized control and
> maintain uniformity among the various filesystem types).

That proposal has been made by many other people, everywhere.  Of
course we could work with that too. 

Personally I rather like the Linux VFS because it does locking etc: Al
Viro has made it very clear that e.g. locking for renames, which is
incredibly hard, is best done once (what you call centralized) than
many times by different file systems.

This is the one single reason that we used the "intent" solution: it
can make use of the VFS infrastructure better than high level calls. 

But again, I'm not religious about this -- I am religious about
getting correctness for clustering file systems. And we have had to do
some other things (like dealing with dentries in highly non-standard
ways) to get correctness.  And of course, we have many problems
left...

- Peter -

> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Lustre-devel mailing list
> Lustre-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lustre-devel
- Peter -