Michel (michel@lespinasse.org) on 1/12/09 wrote:
>
>I'd like to ask, how much SSD knowledge do you think the
>upper layers of the storage stack should have ?

Not a whole lot, really.

>* Making sure that the FS aligns data blocks (I'm thinking
>about the 4k blocks in an ext2 fs) such that no data block
>goes across an erase region boundary (this will also be
>important with spinning disks in the future when they do
>away with 512 byte sectors...)

You really cannot expose the erase region boundary - simply
because it makes no sense. If it matters, you'd be doing
something wrong.

So you do need to expose the "sector size", of course, ie
the size of a minimal (efficient) read or write operation.
And the range of reasonable sizes is actually pretty small:
it's from 512 to 4kB. Anything else will cause huge issues.

A 512b block size means that you can now run all legacy
systems on that disk - which a lot of people still do
care about. It means that you don't need to worry about
any legacy partitioning schemes etc. So there are some real
advantages to it.

A 4kB blocksize is probably acceptable to all modern OS's,
but a 8kB one would not work with Linux, for example. The
4k limit comes from the common x86 page size: we want to do
normal IO in chunks of that size.

Exposing any other kind of odd alignment requirement simply
isn't going to fly. If somebody does that, I'd say "buy
another disk". It's not worth the pain for anybody.

>* Possible FS data placement optimizations to try to have
>files fit in a single erase block, similar to what's being
>done with stride/stripe mke2fs options when using RAID

You'd almost have to be doing something wrong on the SSD
if you need this.

>* Maybe having the disk scheduler spend less effort trying
>to reduce seeks

We are starting to do this, although it doesn't really
appear to be a huge deal. You still want to do some
coalescing of requests, because the per-command overhead
is noticeable, and on at least SATA you're limited to
something like 32 tags, so you cannot have more commands
than that outstanding - which means that you don't want
totally small commands (and in order to coalesce multiple
writes into one, you still need to sort them!)

>and more effort trying to reduce the number of erase
>blocks being written to - for example, when one write
>request will cause a given erase block to be written to,
>maybe the disk scheduler could try to find any dirty
>buffers within that same erase block

We really don't even know what blocks would be in the
same erase block, since it's all translated. But more
importantly, we really don't even care.

What is more likely to matter is:

>* The ext2 optimizations that split inode tables into many
>small subtables, each close to their data blocks, in order
>to reduce seeks, seem quite pointless on SSD

Yes. We're starting to see "SSD flags" on filesystems,
which are about the issue of seeks no longer being very
expensive (for reads in particular). And yes, that impacts
filesystem layout.

For example, you may want to have a block allocator that
tries to just allocate the new blocks entirely linearly.
The end result would suck on a disk, because now when
you read things you need to seek around like mad, but it
is not only simpler but will also generally result in nicer
write patterns.

Of course, you want to balance things. You still want to
have some read locality just to make it cheaper to read
files in one go etc..

So doing some things differently definitely makes
sense. A lot of the optimizations that were done explicitly
for the latencies of rotational media simply do not make
sense any more.

Another example of things we can do at a higher level that
I alluded to in a separate post: telling the SSD when a
block is no longer in use will let the GC and remapping
layer optimize things. There's a cost to sending that
command, of course, and you'd better get it right (because
"undelete" is not going to work), but it likely worth
it.

Linus