Doug Siebert (foo@bar.bar) on 8/22/08 wrote:
>
>I would guess the less than expected performance gain from
>SSDs so far would be mostly due to issues with block sizes
>in the flash device.

Quite frankly, I think that's a bit of a red herring, and
indicative of the weakness of some current-generation SSD's
than anything else.

Big block sizes simply are not acceptable. They will not
be realistic - pretty much ever. The fact is, under
a lot of loads the main IO is to metadata, not large files
(databases are different in this respect, of course), so
a SSD that does badly on small block IO is never going to
do well in real life.

And yes, I do agree that especially for writes, many SSD's
do do badly. It's hopefully changing.

Intel claims that they can get full performance with just
about 4kB reads and writes. That's ok, but I personally
worry (I haven't gotten one of the next-gen drives to test
yet) that the "4kB write" case is a linear write, not
the much more interesting random access.

We'll see.

Anyway, the reason small writes are so important is that
big block-sizes may be realistic for large files, but they
are definitely not realistic for any meta-data
what-so-ever. Directory updates (and in UNIX, inode updates)
are quite often a big part of the whole IO load.

>You can read or write smaller than that (pages are 4k I
>think?) but the erases only happen in block sizes and
>that's what kills you for truly "random writes".

The flash controller needs to do wear leveling anyway
and this is where the real smarts are. This is also where
the big differentiating factors are. You can do stupid
controllers with stupid (or no) wear leveling, and you'll
have a flash that not only wears out, but where performance
absolutely sucks.

>A log-structured filesystem may turn out to be better for
>flash...

I disagree. It's true of some flash, yes. But the fact is,
it's not acceptable if you are going to try to displace
traditional rotating media. Also, it's not even the right
technical solution!

Most filesystems designed for raw flash accesses actually
already are "two-level" - a higher-level more traditional
filesystem (admittedly often with some log-like structures
just due to recovery issues) and a lower-level "block
mapper" infrastructure.

And it's the lower level that really belongs in the flash
controller, and which really does seem to be moving there.
Why? Because the flash controller needs to do a large part
of that anyway due to the whole wear leveling issue,
and because in a very real sense the flash controller is
the only thing that knows the particular characteristics of
the flash anyway.

So this is where the real value-add of flash manufacturing
will be - in the controller. Yeah, yeah, there's a lot of
effort on the manufacturing side too, but you should not
think of flash as just another kind of DRAM DIMM. It's not
just a chunk of oddly addressable memory - it's really
more of a disk.

I'm holding ou fairly high hopes for the SSD's that are
coming out in the next few months, but I also suspect that
there's a lot of room for improvement in that whole block
remapping/wear leveling area. Writes will continue to be
slower than reads because they are more complex, but I
really do expect that the block size issue will be totally
invisible - because anything else will simply NOT WORK.

So forget about 256kB erase blocks. They are totally
irrelevant. If you have to know about them, flash simply
will not succeed.

Linus