Lustre VFS patches for 2.6
cover Lustre VFS patches for 2.6
Hello!
Following this mail, there are nine patches necessary for Lustre support in 2.6. The patches are against latest 2.6 bk snapshot.
Compared to previous sets of patches, this one does not change existing structure and field names therefore leaving kernel VFS API completely intact. Also raw operations approach is changed, extra inode operation is introduced that is supposed to be called at the end of parent lookup and do necessary operations, if possible.
Of course it would be great if these patches would be included into the kernel right away (and that is one of the reasons this set of patches keeps old API intact). Also there were at least some interest in some of the patches from other parties (e.g. Trond Myklebust was interested in some intent changes as I remember) and we are ready to work with those so that the patches will suit their needs as well.
Bye,
Oleg
Quoted 15 lines · Oleg Drokin
Hello!
Following this mail, there are nine patches necessary for Lustre support in 2.6. The patches are against latest 2.6 bk snapshot.
Compared to previous sets of patches, this one does not change existing structure and field names therefore leaving kernel VFS API completely intact. Also raw operations approach is changed, extra inode operation is introduced that is supposed to be called at the end of parent lookup and do necessary operations, if possible.
Of course it would be great if these patches would be included into the kernel right away (and that is one of the reasons this set of patches keeps old API intact). Also there were at least some interest in some of the patches from other parties (e.g. Trond Myklebust was interested in some intent changes as I remember) and we are ready to work with those so that the patches will suit their needs as well.
So do you have plans to submit lustre for inclusion soon? Else merging is completely pointless as it'll fall victim to dead code removal real soon.
Hello!
Quoted 4 lines · Christoph Hellwig
Quoted 3 lines
patches from other parties (e.g. Trond Myklebust was interested in some intent changes as I remember) and we are ready to work with those so that the patches will suit their needs as well.
So do you have plans to submit lustre for inclusion soon? Else merging is
Well, the problems with that is that lustre still evolves pretty quickly, but once it is in kernel, it is sort of set in stone, no more easy changes to the wire protocol, no more big internal changes (fast)...
Quoted 1 line
completely pointless as it'll fall victim to dead code removal real soon.
Well, there is not all that much "dead" code introduced (I hope). Esp. if some of the new intent code will be used by NFS, for example.
And it is not all that dead too, there would be at least one off-tree user ;)
Bye,
Oleg
Quoted 2 lines · Oleg Drokin
Well, there is not all that much "dead" code introduced (I hope). Esp. if some of the new intent code will be used by NFS, for example.
So let's wait until NFS uses it.
Quoted 1 line
And it is not all that dead too, there would be at least one off-tree user ;)
Which is equal to dead for all practical purposes of kernel maintaince.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Interesting, but what exactly does this do? Extra performance? How? Extra security? Avoid deadlocks?
I'm not the kind of guy that just looks into a patch and claims to understand all. :)
Oleg Drokin wrote:
| Hello! | | Following this mail, there are nine patches necessary for Lustre support | in 2.6. The patches are against latest 2.6 bk snapshot. | Compared to previous sets of patches, this one does not change existing | structure and field names therefore leaving kernel VFS API
completely intact.
| Also raw operations approach is changed, extra inode operation is
introduced
| that is supposed to be called at the end of parent lookup and do
necessary
| operations, if possible. | Of course it would be great if these patches would be included into the | kernel right away (and that is one of the reasons this set of patches | keeps old API intact). Also there were at least some interest in some of the | patches from other parties (e.g. Trond Myklebust was interested in some | intent changes as I remember) and we are ready to work with those so that | the patches will suit their needs as well. | | Bye, | Oleg | - | To unsubscribe from this list: send the line "unsubscribe linux-kernel" in | the body of a message to [email protected] | More majordomo info at http://vger.kernel.org/majordomo-info.html | Please read the FAQ at http://www.tux.org/lkml/ |
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFA7BnFhDd4aOud5P8RAhiGAKCJJUqqL9aylG8hkfCAD4GpfMYK+wCdHIj6 njpYVufE205L7MFz04ysdI4=
=tDnN
-----END PGP SIGNATURE-----
Hello!
Quoted 2 lines · John Richard Moser
Interesting, but what exactly does this do? Extra performance? How? Extra security? Avoid deadlocks?
These are just kernel bits necessary for Lustre to work. Without lustre there should be no noticeable difference. Lustre is a cluster filesystem and you can get more info about it at
http://www.lustre.org
Bye,
Oleg
Quoted 1 line · Oleg Drokin
Hello!
Hi Oleg, the patches look good (but what do I know ;). Do you already have a Lustre modules / user-space package to go with them so they could be tested?
Sincerely,
Lars Marowsky-Brée <[email protected]>
Signature · 3 lines
High Availability & Clustering \ ever tried. ever failed. no matter. SUSE Labs, Research and Development | try again. fail again. fail better. SUSE LINUX AG - A Novell company \ -- Samuel Beckett