Date: Sat, 31 May 2014 10:34:54 -0600 From: Warner Losh <imp@bsdimp.com> To: ticso@cicely.de Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, Bernd Walter <ticso@cicely7.cicely.de>, Ian Lepore <ian@freebsd.org> Subject: Re: TRIM on SD cards Message-ID: <127A95E9-82D7-413E-ABDB-81C5C3A027B4@bsdimp.com> In-Reply-To: <20140531132002.GL26883@cicely7.cicely.de> References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <CC7D4DF1-7CE3-445C-9EB2-9CB0856E0AFA@bsdimp.com> <20140531044152.GK43976@funkthat.com> <CAHNYxxMq7K1HeKYXigi8OC159uFJLTr9QCQ2=Vc-ryu0TaW7Hg@mail.gmail.com> <20140531083849.GJ26883@cicely7.cicely.de> <20140531132002.GL26883@cicely7.cicely.de>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On May 31, 2014, at 7:20 AM, Bernd Walter <ticso@cicely7.cicely.de> wrote: > On Sat, May 31, 2014 at 10:38:49AM +0200, Bernd Walter wrote: >> On Sat, May 31, 2014 at 01:21:45PM +0800, Jia-Shiun Li wrote: >>> On Sat, May 31, 2014 at 12:41 PM, John-Mark Gurney <jmg@funkthat.com> wrote: >>>> Warner Losh wrote this message on Fri, May 30, 2014 at 21:55 -0600: >>>>> Blocks of zeros can safely be BIO_DELETEd. Why, because nonexistent blocks are, by definition, all zeros. The only time there?s a problem is when the TRIM doesn?t really TRIM? You don?t need it to be sparse at all. Zeros are zeros. >>>> >>>> Are you sure? TRIM'd space may or may not have a defined value to >>>> return upon read, and what happens if one of those blocks of zeros >>>> belongs to a file that needs those zeros to be zero? >>>> >>>> There are bits that declare if the drive returns zeros or not, so this >>>> would only be safe on those drives.. >>>> >>> >>> For the original question, the need is to keep info about written >>> blocks with the image it self, rather than directly issuing delete on >>> media. I think it is easier to >>> - erase all sdcard blocks before writing image, >>> - teach md to write sparse file, and >>> - teach dd to only write blocks according to info got from sparse image file. >>> >>> In current status block usage info got lost during image creation. >>> Zeroes do not guarantee their existence can be safely ignored. On the >>> other hand read from deleted block does not guarantee zeroes either. I >>> know little about sdcard, but ATA defines a TRIMmed block as being one >>> of the following behaviors on read, according to device: >>> >>> - non-deterministic read, each read *may* get different value >>> - deterministic read value, reads can be *any* fixed value >>> - deterministic read zero, reads are always zero. >>> >>> in practice at least both case 1 & 3 exist. >> >> Well Ok. >> I thought TRIM'ed blocks return zero and it would be possible to >> autodetect zero blocks in images. >> Anyway, this is only one part of my first mail. >> Sorry - my first mail wasn't very clear about this, but there are two >> other parts. >> >> Is there any option to TRIM a filesystem at a later point? >> Newfs can TRIM unused space of new filesystems and tunefs ensure >> TRIM for freshly emptied blocks. >> But what can I do when upgrading old systems? >> With the above I need to copy the data and newfs. >> >> I don't have to use images at all, but I do have to handle USB >> cardreader, unless I go another step further and setup a special >> environment with raw MMC/SD controller to write cards. >> How can I be sure that a given USB SD-reader really handles the TRIM? >> In my case I didn't get an error, but does it mean the blocks are >> really TRIM'ed? > > Ok - so much about "I got no error". > In fact there was one, but this was a kernel message I didn't saw > on my shell: > WARNING: /mnt: TRIM flag on fs but disk does not support TRIM > Interestingly newfs -E worked without errors. > I've tried some USB sticks and readers, but all issued this error > message. > So it seems that either my USB reader or the card don't support TRIM. That’s why I think we’ll need to trim on the actual target. It could also be that umass doesn’t support BIO_DELETE properly by not translating that info to indicate TRIM or UNMAP or WS is supported. It would take some quality time with the da driver to find out for sure, plus looking at the USB specs. CMD38 is listed as mandatory, except for ROM cards. First, the SD card standard guarantees a value, which is good. The bad news is that the value guaranteed varies from card to card. CMD38 is used to erase the data. The standard says: The data at the card after an erase operation is either '0' or '1', depends on the card vendor. The SCR register bit DATA_STAT_AFTER_ERASE (bit 55) defines whether it is '0' or '1'. which is less useful than I’d hoped. This implies either that we hope for it to be 0, then write a trivial program to read blocks and trim the zero’d ones, or we have to know the extents that are valid or invalid, which is much harder…. This suggests looking at umass and/or the SD adapter card would be fruitful… Warner [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTigSuAAoJEGwc0Sh9sBEAt+oP/j1vrTHtdmpoX9OAwsHkQX/8 VxuZZv0rUQ6Sf/7/CtauWtKgo2lOWslMpalf3OIVk0H/8ePsL8jYKLNi30h0DjM5 7dpyVZLnOy7B0b6xyfTz5g2OGbq2bNJ2l7VdjEqN5uXEqE8uwWDbh9YPdn6gfIqV J+S0BpNiIqtTgReLks54k23+oML/1D/ndMCVleSAsJSYCEVKIUPxA8+KGUaK8tBW 1kTwiLV1SaKNO4ltgljXhwPJm1cJUidXSambP8l1OXouu7JpcrlA4K+35vNnbtCl 2EYWNjUWjzRAXHoVFRielE63Zr1TbJwA/Pnhbx2ITRfYdoe1bHfHHrJtGMg83DJM v34TczYN4h2zegbwdJQiaBEpPwaTS9YjRmqYy5ll2tDXsyUFjomPN5mcVzKVLvb9 ItP1TmeS1Oz9HSzWHwF3mPHB5ebc2ytPcBt+zUt3CTUXqRsN8K7BPFRwmCjFM47o gR0VMF5sT72J1NNeG3OebtCiaJVoV9eIV38ISJlZner8u/eZFQxPHMtOoxhMbgLs rYOjmpUgL0EUEX7Cl1c+2YMOew1TetXdIj2L3kakM5lpCKkb8lBzH5EnvhT1wMRz HvZVx53sxgLaflAvBkP30iwmBD0i/TOctGQOJGI2CmcG91TUl2GaR3X3JusWj3eW jWcIAWtbTEPjl34JZ+Ov =xWa+ -----END PGP SIGNATURE-----home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?127A95E9-82D7-413E-ABDB-81C5C3A027B4>