

The Hairy State of Linux Filesystems - jganetsk
http://butnotyet.tumblr.com/post/77317512/hairy-state-of-linux-filesystems

======
blasdel
His argurment is completely bogus -- they're _less slim_ because they share
common code? Did he even look at the symbols he's complaining about?

The only filesystem I have built as a module on my machine is the brand-new
btrfs, it has 223 unresolved symbols, and guess what? They're all basic,
neccessary shit that should obviously be shared: mallocs, libc functions,
concurrency primitives, block IO, inode management, VFS api, generic
datastructures, zlib, etc.

This is more simplicity, not less, and an example of something that fustrates
interlopers about the Linux kernel development culture -- your module _does
not_ make it into vanilla unless you're working at the same level as your
siblings. If you have a systemic improvement to make, you make it to a lower
layer, you don't get to keep your own toys.

This way all the filesystems are improved by the innovations of one -- it took
years for the production-ready XFS code released by SGI to make it into
Linus's tree because it effectively implemented its own VFS tools. Eventually
all its improvements were merged into the VFS layer, the refactored XFS was
merged in, and all users got a performance boost.

------
LogicHoleFlaw
I look forward to seeing what happens to filesystems as solid-state drives
with intelligent controllers become more common.

Optimizing file systems for disc rotational latency is so last century.

~~~
blasdel
But flash memory (even with intelligent controllers) still has physical
constraints to optimize for.

For starters: there's the much larger (and variable) block sizes, the erasure
constraints around blocks (you have to rewrite a whole block to modify a bit),
and the much more atomic power-management possibilities (can do better than
just idle 'spin-down').

~~~
neilc
_you have to rewrite a whole block to modify a bit_

Technically, you can change bits from 1 => 0; you need to erase a whole block
to go from 0 => 1.

~~~
blasdel
All the harder to optimize for -- you could make the bitmasks in the on-disk
format inverted, but it wouldn't help any given that you're almost always
going to modify an integer at the same time. I suppose you could use unary
representations :)

Another related (and potentially conflicting) optimization would be for
powersaving -- in solid state logic, boolean values are represented as 'low'
and 'high', and since 'high' costs more power (and nand gates plentiful), many
circuits get implemented in negative logic. That could mean that an on-disk
format and it's inversion would have different power consumption!

------
mchadwick
Obviously a bit off topic, but his graphic representation is astounding.
Though not quite a Tufte archetype, I gleaned more insight from the image than
the article. Very well done.

------
omouse
Asking the wrong question, looking at the wrong answer.

Who cares about this if the fundamental design of the file-system is flawed...

------
jff
_Slashdot was reporting yesterday that OSes are sliming down._

Don't worry, I got my proton pack right here for that Slimer.

