rwessel (robertwessel@yahoo.com) on 1/6/09 wrote:
>
>You are aware that the official plan, that all the disk
>drive manufacturers have signed on to (MS is on board too),
>is that all new disks introduced starting in 1Q11 will be
>4KB block devices?

It might even happen.

Personally, I'm not a huge believer. The advantages just
aren't there. Sure - for rotational media it really can
be a biggish deal for density. But 1Q11 is a long time
away for somebody who does rotational media, and by then
it's very possible that it's been relegated to more of a
"on-line storage of videos" kind of thing.

And yeah, then nobody will care about a 512-byte
sector on those things.

And yes, maybe flash manufacturers decide that they can
make the remapping tables smaller by also exposing 4kB
sectors. It's debatable, since you'd want to do them as
extents anyway, so it really shouldn't matter much, but
sure, maybe it happens.

Maybe the flash people even do 4kB erase blocks and can
do infinite rewrites, at which point it would matter
for them - because they'd need to do no remapping at all.

But I personally consider that a pipe dream. Not only will
they actually rather just make the erase blocks bigger
rather than smaller, but the wear levelling issues will
remain, and will force people to do all the remapping
logic regardless.

So a 512b vs 4kB sector size is an almost total non-issue
for flash, imho.

>Although probably all will support 512B emulation for at
>least a few years.

.. and especially if you're a flash device, that almost
totally negates any possible advantage of a 4kB block
size. Maybe you can degrade performance, but I suspect
it would actually be easier for them to just keep
a "native" 512-byte block size in their FTL code than
having two very different cases and all the special case
crud.

IOW - once you have to do block remapping and translation
anyway (and I think we both agree that flash needs it, even
in the 4kB era), there really is little difference between
512-byte blocks and 4kB blocks. And if you decide to support
the smaller blocksize some way anyway, you'd be
better off using the remapping code you already have, than
trying to have a bigger "native size" and then have some
odd extra r-m-w layer.

See?

But I dunno. I don't even much care. A 4kB sector size is
perfectly fine by me. It's certainly not totally broken.

What is broken is exposing per-chip erase blocks
and wear-leveling etc. That's crazy. And it always will
be, because when you do a flash disk, you want to do things
like parallel channels, concurrent erase cycles, yadda
yadda yadda. All things that will depend on the exact
flash model, and all things that have absolutely nothing
to do with the actual filesystem that goes on top.

So even if we end up with a 4kB sector size, that doesn't
actually change the situation at all. All the issues wrt
flash remain the same - the only case where a dumb, non-
remapping controller makes sense is for small flash
devices with a single flash chip, in extreme embedded
situations.

Linus