On Sat, Aug 15, 2009 at 7:20 AM, Mark Lord[off-list ref] wrote:

Chris Worley wrote:
..

quoted

So erase blocks are 512 bytes (if I write 512 bytes, an erase block is
now freed)?  Not true.

..

No, erase blocks are typically 512 KILO-bytes, or 1024 sectors.
Logical write blocks are only 512 bytes,

That was my point.

The OS should not make assumptions of the size.

but most drives out there
now actually use 4096 bytes as the native internal write size.

Lots of issues there.

The only existing "in the wild" TRIM-capable SSDs today all incur
large overheads from TRIM

SSD's yes, SSS no.

--> they seem to run a garbage-collection
and erase cycle for each TRIM command, typically taking 100s of milliseconds
regardless of the amount being trimmed.

The OS should not assume a dumb algorithm on the part of the drive.

So it makes send to gather small TRIMs into single larger TRIMs.

If Linux is only to support slow legacy SAS/SATA.

But I think, even better, is to just not bother with the bookkeeping,
and instead have the filesystem periodically just issue a TRIM for all
free blocks within a block group, cycling through the block groups
one by one over time.

That's how I'd like it to work on my own machine here.
Server/enterprise users very likely want something different.

Yes.  I didn't realize this was a laptop-only fix.

Thanks,

Chris

Pluggable architecture, anyone?  :)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>