Hi,
Of course I am totally happy to include or not include the Lustre client
with it. However, that does lead to a sizeable amount of (completely
modular) code, as it depends on the networking, lock manager, logical
volume driver and metadata and object storage clients and the management
framework. It's 2M.
I'd like to also acknowledge that we should remove the small
incompatibility in the names of intents, to preserve api compatibility,
and add an inode method for intent execution. Yes, the LUSTRE_INVALID
flag was discussed on irc with Al Viro: he said that probably I really
needed _something_, he said it's hairy, so it was coded to not affect
anyone that doesn't use that flag.
I have not worked on Coda for 5 years, and have nothing to say about it.
I have recently withdrawn InterMezzo to be helpful to the kernel
community. Of course I would offer the same for Lustre. But as I have
said before, this time there are a lot of resources to maintain this.
Perhaps it is useful to explain that vendors (Novell, Dell, HP and
others) have urged me to enquire if the hooks could go into 2.6. All of
them have really major Lustre customers, running top10 super computing
clusters with Lustre. Having the hooks avoids having to patch vendor
kernels, which breaks support arrangements. As for our position, it's
in fact easier to wait and just collect clever insights from time to
time.
I represent them here. I understand and would respect the wait until
2.7 argument, but I think it is workable to get them into 2.6. Is it
really a big deal to go through these small patches a few more times to
judge if they are safe, and to include them? I think it would help
people who care and support Linux financically. I only hear Christoph
arguing against it, are there other insights?
Again many thanks for spending time to study the patches, it has already
helped Lustre get better.
- Peter -
On Thu, Jun 03, 2004 at 11:53:43AM -0400, Peter J. Braam wrote:
> Perhaps it is useful to explain that vendors (Novell, Dell, HP and
> others) have urged me to enquire if the hooks could go into 2.6. All of
> them have really major Lustre customers, running top10 super computing
> clusters with Lustre. Having the hooks avoids having to patch vendor
> kernels, which breaks support arrangements. As for our position, it's
> in fact easier to wait and just collect clever insights from time to
> time.
>
> I represent them here. I understand and would respect the wait until
> 2.7 argument, but I think it is workable to get them into 2.6. Is it
> really a big deal to go through these small patches a few more times to
> judge if they are safe, and to include them? I think it would help
> people who care and support Linux financically. I only hear Christoph
> arguing against it, are there other insights?
Trond also clearly spoke against it and Anton didn't seem to be impressed
by the code quality of your patches either ;-) Only lmb who certainly
has a vested interest by beeing responsible for cluster at one of the above
mentioned vendors has speaken for it. Given that SLES9 will already have
lustre life should already be much simpler for you. If clusterfs is
actually interested in maintaining lustre as part of the linux kernel I'm
the last one to object, but without you place the burden of maintaining
all the hooks that are very specific to your filesystem on us.
p.s. where's lustre's current cvs tree? I'd like to actually build a module
vs the hooks that you posted and growel in the cvs history a little.