TRIM on SD cards

[Warner Losh]

On May 31, 2014, at 11:48 AM, Ian Lepore <ian at FreeBSD.org> wrote:

> On Sat, 2014-05-31 at 10:45 -0600, Warner Losh wrote:
>> On May 31, 2014, at 4:23 AM, Bernd Walter <ticso at cicely7.cicely.de> wrote:
>> 
>>> On Fri, May 30, 2014 at 09:00:09PM -0600, Ian Lepore wrote:
>>>> On Sat, 2014-05-31 at 02:43 +0200, Bernd Walter wrote:
>>>>> It seems SD cards support a delete command, which FreeBSD supports
>>>>> with the mmcsd driver.
>>>>> newfs and tunefs support TRIM in that new filesystems are trim'ed
>>>>> and the filesystems automatically trim free'ed blocks.
>>>>> So far so good.
>>>>> On the practical side with SD based ARM you don't write filesystems
>>>>> directly via mmcsd.
>>>>> We either create an image, which id dd'ed onto SD or in some cases
>>>>> we use an USB SD drive.
>>>>> With dd the unused blocks are written as well, which effectively
>>>>> hurts by writing data.
>>>>> Is there some kind of dd, which actually don't write zero blocks,
>>>>> or even better does a trim call for them?
>>>> 
>>>> I don't think dd can safely do that.  If it finds a block of zeroes on
>>>> the input side, how does it know it's okay to do a DELETE for those
>>>> (which sets the block to all-bits-on on most flash media).  Maybe it's
>>>> important for that data to really be zero; dd doesn't know.
>>> 
>>> That 1 bit thing is true for raw flash media.
>>> A amanged NAND flash device simply unmaps a logical block from physical
>>> storage.
>>> This is similar to having holes in an ufs file, which per definition
>>> returns zero when reading a hole range.
>>> However from reading the thread it is not save to assume managed flash
>>> devices return zero blocks when reading TRIM'ed space.
>> 
>> One of the things that I did for images years ago was compressed tar files. There was so much variation between CF makers and at the time CF geometry was important to the BIOS, so we made our images as tar balls. We then had a makefile target that would create a partition on the card that was actually there, put boot blocks on it then extract the tarball…  I never have liked DD for creating images, even when LBAs ruled the day because you’d always have to grow/shrink the FS afterwards. The only advantage it had was it was easy… Perhaps it is time to go back to that model? The alternative that wouldn’t suck too bad would be to create variable sized images based on how much data was actually present and ensure there are no holes (or minimal holes) in the filesystem.
>> 
>> Hmmm, if we know WHAT filesystem we’re dealing with, then we could perhaps enhance fsck and/or growfs to BIO_DELETE all the blocks that it knows are free, which would be a useful, data-driven approach that could ensure we start out with a nicely trimmed FS. Given the vagaries of the different kinds of TRIMs and the various translation layers we have, that might be the most robust.
>> 
> I wouldn't at all mind an fsck or growfs option or a standalone tool
> that would issue deletes for unused blocks on an existing filesystem.  I
> have several big SSDs on this system and I had no TRIM support for a
> long time, so there are lots of blocks on the drives that bogusly look
> used to the onboard block management code.

This is precisely why I’d like this…  There are also times one might want to turn TRIM off if you are going to do a huge delete, followed by adding lots of data. It might be faster to just trim what you didn’t refill… Or you might want to have a best-effort time strategy if you know your FS can cope. Then if you get too many, you can discard them and cleanup after the fact on the next boot. The number of use cases here is actually rather large in addition to the one that tisco wants :)

Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20140531/f5ef5f15/attachment.sig>