Forgot your password?
typodupeerror
Data Storage Software Linux

The Hairy State of Linux Filesystems 187

Posted by timothy
from the when-shrinkage-is-what-you-want dept.
RazvanM writes "Do the OSes really shrink? Perhaps the user space (MySQL, CUPS) is getting slimmer, but how about the internals? Using as a metric the number of external calls between the filesystem modules and the rest of the Linux kernel I argue that this is not the case. The evidence is a graph that shows the evolution of 15 filesystems from 2.6.11 to 2.6.28 along with the current state (2.6.28) for 24 filesystems. Some filesystems that stand out are: nfs for leading in both number of calls and speed of growth; ext4 and fuse for their above-average speed of growth and 9p for its roller coaster path."
This discussion has been archived. No new comments can be posted.

The Hairy State of Linux Filesystems

Comments Filter:
  • by epiphani (254981) <epiphaniNO@SPAMdal.net> on Wednesday February 11, 2009 @05:19PM (#26819071)

    Two things of note with NFS...

    1. NFSv4 support was added. v4 is complex and has a lot of authentication stuff in it that wasn't in v3.

    2. SunRPC is "part" of the NFS tree, but is effectively just a transport layer. It is completely abstracted, hence the numbers of symbols. It could be used for other stuff, so it pushes up that number too.

  • Thoughts (Score:5, Informative)

    by stevied (169) * on Wednesday February 11, 2009 @05:19PM (#26819089)

    Thoughts:

    - This is measuring, I believe, calls to different functions; a call to one function from multiple places is only counted once. So it's really a measure of the diversity of external calls.

    - Size and complexity aren't necessarily the same thing. It's actually possible that as common functionality is abstracted out of filesystems, they get smaller but make more external calls. There was a point a few years ago when this was happening at quite a rapid pace in the fs code, I don't know if it is still true.

    - Journalled filesystems and networked filesystems are pretty complex creatures by their nature, the quoted numbers don't seem unreasonable. NFS in particular implements (IIRC) protocol versions 2, 3 and 4, and 4 had a lot of new stuff.

  • Re:Is this a story? (Score:5, Informative)

    by hedwards (940851) on Wednesday February 11, 2009 @05:35PM (#26819335)

    I don't like that it was restricted to just Linux FSes, comparing it against ones available for other OSes, would have given it at least some context. Based upon the article, it sounds like Linux is being trounced. But, one doesn't really know because there isn't a comparison to other OSes to have any clue whatsoever.

  • by svnt (697929) on Wednesday February 11, 2009 @05:36PM (#26819349)

    Unfortunately all "speed of growth" is referring to is the rate of increase of the number of filesystem kernel calls of a particular filesystem from version 2.6.11 to 2.6.28 of the Linux kernel.

    Nothing to do with any sort of performance metric.

  • Check out Tux3 (Score:5, Informative)

    by Daniel Phillips (238627) on Wednesday February 11, 2009 @05:47PM (#26819495)

    While Tux3 [tux3.org] is not yet ready to run on your desktop, and won't be for a good many months, it is relatively trim at around 6K lines, and is expected to be somewhere around 10K complete with versioning, recovery and proper code comments. Of course, that will still be significant growth in a few months, and nothing says it won't just keep growing. But Tux3 is starting much smaller than its peers, and already has a pretty good range of "big filesystem" features. One of our guiding principles is to keep it tight, therefore leaving fewer places for bugs to hide.

  • Re:Where's NTFS ? (Score:5, Informative)

    by ADRA (37398) on Wednesday February 11, 2009 @05:57PM (#26819617)

    1. The AC was a satire. In fact, I remember reading those exact lines at least once before. Its actually quite funny, so props to the original troll for making something really nice to read.

    2. ntfs-3g should be all you need to handle read/writes in Linux these days. I think its nested on top of fuse, so you'll probably need it as well. (Side note, glad Linus finally caved on allowing fuse into his kernel releases)

    3. WinFS is a meta-layer on top of NTFS, so not in itself a disk file-system.

  • Re:Thoughts (Score:3, Informative)

    by stevied (169) * on Wednesday February 11, 2009 @06:09PM (#26819777)

    Yeah. There was a stage (starting in the 2.3 days, I think) where the kernel gradually grew a very complete "framework" which the filesystems just plugged into, basically filling in the gaps. Straightforward, unixy filesystems became ridiculously simple to implement, and even the more complex ones got a lot of non-essential complexity combed out. Of course, there were a fair few specialized callbacks and utility functions made available to the fs code as part of this, and that may have pushed the unique call count up.

  • by DrYak (748999) on Wednesday February 11, 2009 @06:36PM (#26820119) Homepage

    Sorry to disrupt the trolling copy-pasta, but :
    Is this post on ZDNet's forum [zdnet.com] the original form of this troll ?
    Or is this troll older, and jerryleecooper was already copying it from somewhere else ?

    I'm just curious to know where this fine piece of humorous trolling was originally born.

  • Re:At least Reiser (Score:5, Informative)

    by GF678 (1453005) on Wednesday February 11, 2009 @06:42PM (#26820195)

    Off topic, but just in case anyone is curious as to how Hans Reiser is doing in prison...

    Not particularly well so far: http://www.kcbs.com/pages/3634907.php [kcbs.com]?

  • Re:Yes/no (Score:5, Informative)

    by ckaminski (82854) <(moc.xobop) (ta) (iksnimakc)> on Wednesday February 11, 2009 @06:49PM (#26820291) Homepage
    Okay, you MIGHT, just MIGHT have a point with a microkernel architecture, or if the filesystems are implemented in user space (Fuse), but is irrelevant in kernel modules in Linux - you're not crossing interrupt boundaries, so calling a kernel function is just as cost effective as rolling your own.
  • Re:Yes/no (Score:5, Informative)

    by Daniel Phillips (238627) on Wednesday February 11, 2009 @07:28PM (#26820779)

    Function calls are not free. Especially in kernel space. Everything costs time. You need to do the most you can with the least instructions. 100 lines of inline code will probably run faster than a function call.

    Never having been one to accept unsupported claims at face value, I just tested that assertion on a Pentim-M here, with a small C program that either calls a function to increment a counter, or directly increments the counter a number of times. I compiled with O0 to be sure gcc does not change around my code at all. Just the instructions, thanks. Funny thing? A hundred increments runs within 1% of the speed of 100 calls to a function to do the increment. And yes I unrolled those calls to isolate the cost of what I was measuring. So... rather surprisingly, the cost of these function calls is as close as doesn't matter, to exactly zero.

    Loops on the other hand... cost a huge amount. I won't get into details. But Intel clearly does something to optimize function calls in microcode, or probably even hardware. Function calls just don't cost what you think they do. In many cases, the function call will cost less by not trashing as much of that incredibly valuable L1 instruction cache.

Whenever a system becomes completely defined, some damn fool discovers something which either abolishes the system or expands it beyond recognition.

Working...