[clug] best filesystem for solid state drive?

[Daniel Pittman]

Sanders King <sandersking at hotmail.com> writes:

> I found this article very interesting.  It talks about a kind of circular
> file system suitable for SSDs because it doesn't reuse a 'sector' until it
> has completely lapped the disk.  However it may only be for S/ATA SSDs; I
> have no idea whether it would be best for a flash drive.

Other than the I/O bandwidth and IOPS count, it makes pretty much no
difference what bus sits between your flash chips and your CPU.  So, if NILFS
is good on one it should be good on the other, modulo the general performance
of the two devices.  (Plus, CF devices are PATA connected flash ;)

> http://www.linux-mag.com/cache/7345/1.html

That is a very fluffy article, though, without touching on a lot of the real
technical considerations.  Specifically, they claim:

    a log-structured file system recovers from a crash extremely fast and the
    amount of time is independent of the size of the file system.

This might be a property of NILFS, but it is not a general property of log
structured file systems as that quote suggests; it also doesn't touch on the
question of NILFS mount performance *after* "recovery from a crash" or in the
normal case.

Traditionally, log structured file systems need to scan the log at boot to
build their filesystem image; perhaps NILFS uses some other technique to avoid
that, such as storing a traditional tree-structure inode map on disk, but that
isn't discussed.

That could mean almost instance "crash recovery", followed by a very, very
slow "normal mount" process ... which kind of defeats the purpose.  I suppose
that it has some sensible (and fast) implementation, but...


The article lists "read-ahead for metadata and data" as a feature which is
probably true, but is also a bit ... of advertising, really, since there isn't
a Linux filesystem that doesn't support read-ahead ... at the VFS level, if
nothing else.


They also gloss over the big killer of a log structured file system: garbage
collection; NILFS uses GC-by-copying, which means that when log space needs to
be reclaimed it is done through copying blocks from the tail to compress them.

Their claim that it uses an innovative user-space daemon to do GC is also
interesting, and it would have been nice to see discussion about how that
synchronises with the kernel page-cache for NILFS metadata while it moves
blocks in the log...

(Although, I suspect that in this case they simply misunderstood and the
 daemon simply reclaims older checkpoints through a standard interface, and
 all the actual log garbage collection is done in-kernel...)


Also, NILFS apparently doesn't support extended attributes, so no Samba POSIX
attributes, and no SELinux or other EA use on it.


So, yeah, interesting, but rather fluffy.  I would be interested to see some
benchmarks on a well used NILFS-on-SSD installation where the log was
fragmented, though.  It /could/ be good, but without that check...

Regards,
        Daniel

The Intel SSD had exactly the same GC issue, as it happens. :)