IntelUser2000 (Intel_user2000@yahoo.ca) on 1/7/09 wrote:
>
>Linus, you might want to know that the X25-M drives slow
>down after usage:

I don't think it's not quite that simple.

What's going on is almost certainly a combination of
factors:

- almost any block mapping will be simplified by bigger
extents.

Result: especially after running benchmarks that just
do small random writes for a long time, the block
remapping tables will be maximally fragmented and have
just single-block extents.

This will likely cause a performance dip because the
remapping tables don't fit in the RAM caches of the
controller, so it will end up doing more lookups to the
flash.

It's quite possible that the flash remapping layer will
end up running extra GC cycles at points to avoid this
worst-case situation, and that will obviously show up
as a performance dip.

The good news is that while "random write performance" is
actually meaningful, it's very seldom the case that it's
dominant (ie it's important because it happens occasionally,
not because it's a common case!)

So in most use, you'd have a mix of small random writes
and larger contiguous ones, and the realistic situation is
that the remapping never gets really bad - at least not as
bad as the extreme benchmarks make it.

The other issue is:

- garbage collection is much easier if you have
lots of free space.

This is to some degree the bigger issue. It's also a
possible "value add" issue, ie I would actually expect
flash disk manufacturers to start differentiating their
drives based on "performance vs capacity".

You can effectively make a higher-performance drive by
leaving more of the drive for internal use, in order to
make GC be smoother/faster. For example, when the Intel
drives are 80GB, that means that they really have 80GiB
(binary) of flash, but only expose 80GB (decimal) of it
as disk, so you have about 6GB of "free flash" to do
GC with.

Now, you could actually sell the exact same drive
with a capacity of just 75GB, and you'd essentially have
doubled your "scratch area" to do GC in. End result:
smoother garbage collection with fewer GC spikes.

Quick! Sell the thing as a server drive! Server people
are used to paying extra for smaller drives!

See?

The second issue shows up when you do any writes to disk:
out of the factory, the remapping tables are likely all
empty, so the disk can actually use all of the drive
as a scratch area, and thus have a much easier time doing
GC.

But once you've written to the drive enough, it will only
have that small (well, not so small) 6GB scratch area. See
how that goes? And this is actually totally independent of
whether you did small or large writes, although large
writes will make GC easier in general, so the relative
performance degradation will probably hit the smaller
writes more.

So yes, performance will drop over time, down to a level
where it stabilizes.

However, there is some good news: you can actually tell
the drives to set aside more memory for scratch space.

If your OS supports it, and if your filesystem
is smart enough, it can actually do a "drop data" command
when you delete files, and rather than remapping those
blocks, the flash controller can then add them to the
scratch area.

So flash is certainly not trivial, and you can tune for
performance in different ways. But having now used flash
drives in a couple of my machines for the last couple of
months, I can tell you that it's wonderful when done well.

And I'm sure that people will improve on the Intel drives.
I'm not saying that they are perfect. But yes, they do
degrade a bit until they hit a baseline plateau of write
performance, but if you look at the numbers, even that
degraded plateau is a couple of orders of magnitude better
than rotating media.

Linus