On May 24, 2016, at 2:47 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > On Mon, May 23, 2016 at 03:09:49PM +0200, Andreas Gruenbacher wrote: >> I'm reasonably confident about the core and cifs changes in this patch. >> The lustre code is pretty weird though, so could I please get a careful >> review on the changes there? > > Lustre is in the staging tree because it's an unrescuable piece of junk. > Please just ignore it and move the proper parts of the kernel forward. Don't be shy Christoph, tell us how you really feel about Lustre... :-) Fortunately, that "piece of junk" is working fine and is running on most of the supercomputers in the world (9 of the top 10, 70%+ of the top 100, ...) with several sites having 50PB+ of storage, and 1TB/s+ to 20000+ clients, in a single coherent POSIX filesystem. It's true that the staging client isn't getting cleaned up as fast as anyone likes, but that is because it is complex software in use at many sites for many years and we can't just stop to completely rewrite the code and hope it still works. Even XFS took many years to get rid of the IRIX wrapping layers, and still does a lot of things outside of the VFS/VM (stats, memory allocation, IO submission, etc.) because the VFS/VM doesn't work the way XFS wants it to (or vice versa). This is not a slight against XFS, just a sign that non-trivial filesystems take a long time to change while maintaining existing functionality. This is mainly a difference in how code is added to the kernel today vs. how it was added back then. Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
