On Fri, 2011-02-04 at 18:30 -0600, R. Ramesh wrote:
> I do not have SSD. I have a USB flash drive - went cheap on this :-)
>
> Regardless of the above, still every write by the kernel has to be
> translated in to NAND writes. I have read in more than one place that
> these writes will be in units of erase-block size regardless of the
> kernel IO size.
I could be wrong, but I've always understood that you could write less
than an erase-block size of data, just that the part of NAND written to
can't have previously been used since the last erase. E.g.
- Erase 128kB block
- Write 64kB to first half of block
- Later write 64kB to second half of block
- Need to erase whole 128kB block before it can be written to again.
> I am simply trying to map the X kernel writes in to Y
> erase-block writes. Note that I do not map it specific erase-block, but
> to some erase-block. So I only worry about the block counts not the
> block addresses. That is why my calculations are based on total number
> of erase-blocks writes available (= 16G/512k*10000 = 327680000) before
> the device goes bad. So to me the life of flash is 327680000 erase-block
> writes. Now how many hours is it? To answer this, I need to understand
> what vmstat -d prints.
If I'm right about partial writes to a NAND erase-block, then I don't
think that you need to try and factor in erase block sizes, just use the
fact that for each byte written a byte must have been previously erased.
Assuming that the flash controller only erases full blocks (it won't be
that efficient though) then you just calculate the total amount of data
that can be written to the disk. In your case, 16GB disk * 10000 erases
= 160TB data before the disk expires.
In my previous job when we were thinking about wear on MMC cards due to
demand paging, the calculations showed that if you wrote continuously to
the card at it's maximum rate supported it would last several years. It
was at that point I stopped worrying about flash wear :-)