Should the Lustre preparation patches go in? [LWN.net]

Lustre is a high-performance, distributed filesystem intended for use in large clusters. It is the latest effort from Peter Braam, who has, in the past, been responsible for the Coda and InterMezzo filesystems. Lustre has not been proposed for merging yet, but it is already in production use at a number of large supercomputing centers. Companies like Dell, Cray, and HP have been helping with its development.

Mr. Braam has recently posted the second iteration of a patch intended to pave the way for inclusion of Lustre. This patch exports some symbols needed by Lustre and makes various virtual filesystem changes. With this patch in place, sites using Lustre would be able to load the filesystem as a separate module without having to patch the kernel directly. Since many of these sites, it seems, use "enterprise" distributions and cannot patch their kernels without invalidating their support agreements, this matters. Almost everybody involved would like Lustre to be usable on mainline kernels.

Most of the technical objections to the Lustre patches have been addressed; to that end, many changes were made since the first posting. There remains one objection which can still be heard from a small number of developers, however: the patch should not be merged because it provides interfaces which are not used by any code in the kernel tree. This argument has been heard before; the Linux security module patches, for example, were opposed on this basis.

It is not hard to understand a general reluctance to include (seemingly) unused APIs in the kernel. If an interface is not in active use, chances are that, when somebody does try to use it, they will find that it does not work as advertised. Unused code tends to rot over time. And all code bloats the kernel, so it makes sense to hold off on adding new code until there is a clear use for it.

It is also true, however, that the addition of new interfaces can help drive development in useful directions. The hooks needed by Lustre should be useful for a number of distributed filesystems, starting with NFS and going on to the various other cluster-oriented filesystems. Until the new interface is available, however, no filesystem will start using it. And, in any case, there is a clear user here in the form of Lustre, which is an available, GPL-licensed filesystem.

Your editor, putting on his highly unreliable clairvoyant cap, figures that the Lustre developers will eventually get their wish. Certain developers will likely make them sweat for it, however, forcing a few more iterations on the patch before it can be accepted. But in the end, nobody disagrees with the goal (being to provide a high-quality distributed filesystem for high-performance clusters) and the patches were written with a relatively light hand. There is no real reason to keep them out of the kernel.

(Log in to post comments)

Should the Lustre preparation patches go in?

Posted Jun 11, 2004 16:54 UTC (Fri) by iabervon (subscriber, #722) [Link]

It seems to me that the preparation patches shouldn't go in until a user of them is at least proposed for inclusion. In evaluating an interface, it is often important to see exactly how it is intended to be used; it can turn out that an API looks fine until you look at the code which uses it, at which point it becomes clear that the code that uses it has to work around annoying aspects of the API.

It shouldn't be necessary for Lustre to actually get included (or NFS et al to get modified to use these hooks) in order to get the preparation patches in, but I think that at least the portions that use the new APIs should be critiqued.

Should the Lustre preparation patches go in?

Posted Jun 11, 2004 18:00 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

it can turn out that an API looks fine until you look at the code which uses it, at which point it becomes clear that the code that uses it has to work around annoying aspects of the API.

Remember that the Lustre people are already using these interfaces, and have plenty of experience with them. It couldn't be any more clear to someone else if they are working around annoying aspects of the API they designed.

So really the only evaluation to be done in this area is whether the API is good for some hypothetical future user. And considering the hypothetical future user is exactly contrary to the mindset that says leave out the Lustre APIs because Lustre isn't in-tree now.

A good interface stands on its own. An interface designed for a particular present user, or many particular users, is usually pretty bad.

The "don't have interfaces for out-of-tree modules" philosophy has nothing to do with making good interfaces. It has to do with having the flexibility to change the interfaces later. If you can't modify all the users of an interface, then you're either stuck with never changing it, or you regularly break things.

Linux developers have always abhorred the leave it alone -- you might break something philosophy, so interfaces for out-of-tree modules are anathema to their development style.

Should the Lustre preparation patches go in?

Posted Jun 12, 2004 0:16 UTC (Sat) by iabervon (subscriber, #722) [Link]

The issue is that the API could be usable, but only if you do something
that the core developers wouldn't accept. You're right that they wouldn't
have made it awkward to use, but it might be impossible to close some
race, or only work in a module, or something like that. Just looking at
the interface won't necessarily tell you if it is fundamentally flawed in
some way as to cause bugs in the user code rather than in the
implementation.