Joern Engel (joern@logfs.org) on 1/6/09 wrote:
>
>Everyone agrees that hard disks are block devices, not
>byte devices. If you decided to write byte-aligned to
>a hard disks, you would get problems as well.

I'm not arguing for byte-addressability.

But I do think that the people who say that sector sizes
will grow are largely deluding themselves. The reason for
a 512-byte sector is not that disks used to be smaller:
it's simply that it was a reasonable choice for granularity
when you do need blocking, but also know that a lot of
data is not big streaming stuff.

And that really hasn't gone away. Some files are bigger,
yes, but on the other hand to balance that out, there is
a huge compatibility advantage to 512-byte blocks.

And there is no reason to think that 512-byte blocking
doesn't work. Sure, you can write in bigger chunks, and a
good remapping layer will take advantage of that by doing
the remapping using extents. That goes without saying. So
you can still get better behavior by doing big writes, but
there is no reason to think that you should drop capability
or have a disastrous performance fall-off just because
you can also do smaller 512-byte blocks.

In fact, if anything, getting rid of rotational media
makes for a much weaker case of growing the block size,
since the whole inter-gap timing thing doesn't exist any
more.

>Of of my main gripes with SSDs is that they are trying to
>be too smart.

Trust me, they aren't. They are not "trying" very hard at
all - they're largely being very stupid about the features
they do expose.

The Intel drives (and hopefully the next-gen drives of
a lot of other manufacturers) are finally actually
trying to be smarter about it, and it's working very well
indeed.

It's working much better than trying to do the
same in software, because on a software level, you really
do have issues like years and years of legacy that also
needs to support all those normal disks.

If you make flash look like raw flash, you automatically
cannot share the code with a sane filesystem on a disk.
In the Linux space, for example, you have to use special
filesystems, and can share basically no code with all the
disk-based ones. End result: bad.

And the fact is, flash controllers can do a good
job. All your worries are based on false data.

More importantly, flash controllers fundamentally can
always do a better job. Not only are they closer
to the media and have lower latencies for critical R-M-W
updates, but they know characteristics of the media
much better.

For example, they may well be able to easily update single
bytes on the media. Yes, you have to erase in blocks, but
then you may be able to write stuff (once erased) one word
at a time, and thus (for example) do things like the
remapping tables very differently - because you have a log
that is low-latency and word-addressable.

But that's only true for the flash controller. It's not
true for the host.

This really is fundamentally no different than a regular
rotational media controller. Yes, early on, people really
did use to control rotational media from the host CPU
itself - doing the MFM encoding and all the timings in
software. It "worked", and yes, it was cheaper than having
a separate controller.

You know what? People don't do that any more. And disks
actually improved faster because of embedded controllers,
because now the controller could be much more tightly tied
to the media itself.

IOW, making the media and the controller be more tightly
coupled not only made it much easier on software, but
exactly because it hid a lot of the low-level details, it
actually allowed the media to evolve and have new features
and interfaces.

It reasonably allowed for media to have faulty spots, for
example. Yes, people tried to do bad-block mapping in the
filesystem too, but let's face it, it really never worked
very well.

But it allowed the controller to also simply get better
connections to the platter, and do things that could not
have been done if they were done on the host.

The exact same thing is true of flash. Having a
flash controller means not only that it can reasonably do
remapping of bad areas (higher flash yields, anybody?),
but it also means that a flash manufacturer can decide to
much more easily introduce extended interfaces for the
controller - exactly because there is that abstraction
between them. So you can much more easily introduce things
like asynchronous block erase cycles etc - without having
to teach legacy filesystems about it.

So a smarter flash controller is good for the user (and
the software) side, but it's actually good for the flash
manufacturer too. The higher-level abstraction is what will
allow flash manufacturers to do different things.

Linus