

NILFS: A File System to Make SSDs Scream - linuxmag
http://www.linux-mag.com/id/7345

======
wmf
Note that NILFS makes _old, crappy_ SSDs scream. Also, the article makes NILFS
look good by comparing it to old filesystems, not COW-tree filesystems that
are the current state of the art. NILFS may have merit, but this article
doesn't demonstrate that in an honest way.

~~~
davidmathers
What's a COW-tree? And which filesystems are COW-tree filesystems?

~~~
wmf
Copy-on-write tree. See WAFL, ZFS, and Btrfs.

~~~
davidmathers
There's one comparison to ZFS:

 _One of the most noticeable features of NILFS is that it can “continuously
and automatically save instantaneous states of the file system without
interrupting service”. NILFS refers to these as checkpoints. In contrast,
other file systems such as ZFS, can provide snapshots but they have to suspend
operation to perform the snapshot operation. NILFS doesn’t have to do this.
The snapshots (checkpoints) are part of the file system design itself._

~~~
wmf
AFAIK ZFS never "suspends operation", whatever that means.

~~~
rbanffy
Pretty much doesn't as a COW fs does not need to.

------
maggit
Pardon my ignorance of SSDs and how they work, but aren't seek times supposed
to be low or negligible? Isn't a log-structured FS optimised for a disk with
high seek time?

I guess my questions boil down to:

1\. Why is this approach fast on an SSD? Wouldn't the performance boost be
more noticeable on a spinning disk?

2\. Shouldn't someone try to make an FS optimised for SSD characteristics?
Have someone already done this?

~~~
wmf
_Isn't a log-structured FS optimised for a disk with high seek time?_

Sort of. It makes writes sequential (and thus fast) and reads nearly random
(and thus slow).

 _Why is this approach fast on an SSD? Wouldn't the performance boost be more
noticeable on a spinning disk?_

Old, crappy SSDs have very slow random writes (which is like seeking), so log
structuring increases write performance by orders of magnitude. Since random
and sequential reads are equally fast on SSDs, the randomized layout doesn't
hurt read performance as it does on disks.

 _Shouldn't someone try to make an FS optimised for SSD characteristics?_

If the characteristics are different for every SSD model, no. Recent SSDs are
becoming insensitive to access pattern, so the correct "optimization" is
probably to perform no optimizations other than trim.

~~~
limmeau
Trim?

~~~
wmf
Trim is a command that punches a hole in the SSD (much like a sparse file) so
that the SSD doesn't waste effort managing unallocated space.

------
voberoi
While a speed boost is great and all, don't you have the added concern of
making sure your blocks don't wear out on an SSD? Because log structured file
systems commit metadata and data in large sequential writes to the hard drive,
they have background processes that constantly move data around to prevent
massive fragmentation from files that are later deleted. It seems like there
would just be too much writing going on if what you want is a long-lasting
SSD.

They do mention in the article that it would be a bad idea to use NILFS on
your root partition because of heavy traffic, so lets say I decide to use it
on a volume where I store all my media (where I pretty much write once, read a
lot, and never delete). Now, a) why would I use an SSD for this given that
they're so much more expensive and b) wouldn't I get comparable performance
using an HDD here since my files will be laid out pretty much sequentially
given my workload? Doesn't the same apply to companies storing mounds of data?
Where is the middle ground where I would want to use NILFS on an SSD? One
where I a) won't be sending enough write traffic to my drive to wear out my
SSD too quickly and b) will be reading a lot of random blocks?

What am I missing? I see the merits in using NILFS, but I just don't see the
purpose in comparing its performance against other filesystems on SSD's.

------
wglb
Ah. Garbage collection for file systems. With screaming, to boot.

Wasn't some work done on log-structured file systems done by DEC some time
ago? I can't find a reference to it.

~~~
davidw
> Wasn't some work done on log-structured file systems done by DEC some time
> ago? I can't find a reference to it.

Didn't Ousterhout (who, amongst other things, worked on a log based file
system) work there on sabbatical?

<http://en.wikipedia.org/wiki/John_Ousterhout>

~~~
ciupicri
He's mentioned in the article along with another guy.

> The concept was developed by John Ousterhout of TCL fame and Fred Douglis.

------
jsonscripter
How would you implement a swap on such a filesystem? You couldn't, could you?

Oh, and the jokes about having _NILFS_ on your _hard drive_ are going to be so
lame...

~~~
jerf
"How would you implement a swap on such a filesystem? You couldn't, could
you?"

The days of "swap" are numbered. The future is a smart memory hierarchy that
uses knowledge about size/speed tradeoffs to make smart decisions about where
to store things, but that won't look much like "swap".

Even with SSDs, it has become very unusual for "the system is currently
swapping" to mean anything other than "the system's performance
characteristics just became completely unacceptable". I stopped using a swap
partition somewhere around 512MB to 1GB, and now my laptop that I didn't even
try to max out the memory on shipped with 4GB. I can't hardly even fill up the
_cached buffers_ in 4GB in any reasonable period of time.

(Please note the difference between "very unusual" and "never". In fact, I can
cite a server in my care that benefits from using a bit of swap. But that
server is the _exception_ , not the rule.)

~~~
jongraehl
We'll still have swap as long as CPUs support virtual memory. Nothing beats
using a dumb programming language and process model, and without explicitly
deciding anything, being able to scale past physical memory until your working
set just barely fits.

Further, there may be some performance benefit to swapping idle process memory
to make room for more buffer cache.

It's true that for interactive use (especially a laptop with spun-down
drives), you may be happy without swap. But I don't see the facility being
mothballed.

