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

Bryan Henderson hbryan at us.ibm.com
Tue Jan 7 17:29:00 GMT 2003




>Is the objection really just to the terminology, then?

Partly the terminology, and partly the things that the terminology implies.
Those who support this name must do so because they expect the interface to
have some properties of intent.  But I've argued that it cannot be a true
intent declaration, and therefore any approximation to intent will cause
trouble.

>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 understand that it was a design
>compromise motivated in no small part by the desire to minimize changes
>to the Linux VFS at this stage.

That explanation makes a lot of sense.  What it really boils down to is
that the parameters aren't so much a declaration of intent as a revelation
of the context in which the caller is making the call.  In other words, a
contravention of modularity.  That is always a minimal-lines-of-code
solution to a protocol problem.  It's a heavy design tradeoff, though.

>Do you use "the VFS caller" to mean "the code that calls into the VFS",
>or "the caller of the intent-handling operations, which is the VFS"?

One of the irritating things about Linux filesystem discussions is the
diversity of terminology.  Several of the most key terms, including "VFS"
are used to mean multiple very different things.  In this case, you are
clearly using "VFS" to mean the Linux code found in the 'fs' directory.
That's common, but it is also common to use it to refer to the code found
in directories such as 'fs/ext2'.  I don't find either of those definitions
useful.  To me, VFS has always been the name of the protocol that said
pieces of code use to talk to each other.  And it applies in general to all
operating systems that have such an interface inside them.  The name "FS"
works better for the code in the 'fs' directory (not just because that's
what the directory is called, but also because the oldest documents
describing it call it that).  The term "filesystem driver" is far more
descriptive, unambiguous, and universal for the code in fs/ext2.  But
people most often refer to that code as "a filesystem."  Along with 5 other
things they use the word "filesystem" for.

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.





More information about the samba-technical mailing list