On Sat, Aug 15, 2009 at 7:20 AM, Mark Lord<liml@xxxxxx> wrote: > Chris Worley wrote: > .. >> >> 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 from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
