Aaron Spink (aaronspink@notearthlink.net) on 1/20/11 wrote:
---------------------------
>anon (anon@anon.com) on 1/20/11 wrote:
>---------------------------
>>So when you say "enough", it is enough to do some checkpointing and particularly
>>because a lot of data indeed does have to go down to non volatile media so not much is required to be written..
>>
>As I said, it varies by drive. Some drives have enough capacitance to fully write out a full map table.

I'll bet you $2 you're wrong, for any drive that does granular tracking of sectors.

What's Intel SSD capacity? About 2^29 512 byte sectors?

So a full map table needs to track 2^29 LBAs to mapping 2^29 PBAs. Which is 2^29*29 bits (assuming no other bits for future expansion or tracking any additional states).

That's 1.8GB.

If you do not store a full map, but perhaps a simple valid/invalid map, then that's still 64MB.

So maybe the top end enterprise cards that have battery backed cache or a lot of super caps, maybe. Common "good" commodity SSDs like Intel's? You tell me.


>>I don't think I can actually. Maybe in a couple of months, which I'm aware isn't very satisfactory.
>>
>Which I think is part of our problem with this discussion. We lack a lot of real
>world data. Though fundamentally there really is no reason that the TRIM command
>on the device should take any real time, certainly not to get the command response/completion out.

/We lack/we can't share/

But actually I think Linus has seen empirical evidence to show that trim can be very slow. The argument isn't about that a $20,000 card can theoretically do trim really nicely...

>>For the mapping table, it doesn't really save anything because it's modifying the
>>same cachelines as the trim -- ie. switching from old to new PBA shouldn't be significantly
>>more expensive than switching from unused to new PBA.
>>
>You also have to update the PBA state.

No. Think about how a log structured FTL works. A block is naturally old/invalid due to no LBA pointing to it.

I don't know -- maybe you have experience with an FTL that does something differently that makes rewrite significantly more expensive than write-unallocated. But that might be among one of the suboptimal ones that doesn't make its GC algorithms work in the common case, and therefore assume that everyone else will fix up your problem by doing trims.

:)