| |||||||||||||
The new file systems:The new file systems:Posted Nov 30, 2006 9:34 UTC (Thu) by job (guest, #670)Parent article: Kernel release status
I know a lot of people prefer OCFS2 to GFS, because of the simpler, more "Linux-like" design. Is this still the case with GFS2? I would like to request an LWN article with in depth comparisons of the two, for all our exciting cluster needs.
When I'm at it (wishful thinking, that is), I would also like the ext4 developers to at least consider tail packing! That and the directory hashing has always been the greatest functionality of ReiserFS, especially for all those spool directories and maildirs.
(Log in to post comments)
The new file systems: Posted Nov 30, 2006 10:22 UTC (Thu) by mingo (subscriber, #31122) [Link] I know a lot of people prefer OCFS2 to GFS, because of the simpler, more "Linux-like" design. Is this still the case with GFS2? I would like to request an LWN article with in depth comparisons of the two, for all our exciting cluster needs.Here's the linecount of both of them:
GFS2: 26954 lines of code
+DLM: 11939 lines of code (generic lock manager)
= 38893 lines of code
ocfs2: 44952 lines of code (integrated lock manager)
So in that metric, GFS2 is simpler. It has also been cleaned up significantly and the code is very much "Linux-like".
In any case, more in-upstream-kernel filesystem competition is good and Linux can only win as a result :-)
The new file systems: Posted Nov 30, 2006 18:04 UTC (Thu) by bronson (subscriber, #4806) [Link] Just thinking idly here... I'd also be very happy if ext4 did tail packing. That said, I'd also like a flag that turns off all possible optimizations, reducing the amount of code that runs to a bare minimum. My mail spool is an example of a high-use volume where I can tolerate a bug or two: mount it -o3. My sarbanes-oxley archive is big, dumb, and slow, but I need it to be TOTALLY stable: mount it -o0.
I'll second your desire to see a cluster filesystem article too. :)
The new file systems: Posted Nov 30, 2006 21:37 UTC (Thu) by proski (subscriber, #104) [Link] More options to choose from means less test coverage for every single combination of the options. I'd rather stick with the defaults.Safety of data is obtained through procedures, not through clever coding. Most data losses are caused by improper procedures (such as missing backups or security breaches) rather than by the filesystem software failures. Consider using well tested code as part of the procedure. I'm very interested in the precise timestamps, but they are not in 2.6.19 yet.
|
|||||||||||||