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>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_FEDB7C16-ECD3-453F-AEEE-53CC88EEDA19 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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. >>>>=20 >>>> 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? >>>>=20 >>>> There are bits that declare if the drive returns zeros or not, so = this >>>> would only be safe on those drives.. >>>>=20 >>>=20 >>> 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. >>>=20 >>> 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: >>>=20 >>> - 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. >>>=20 >>> in practice at least both case 1 & 3 exist. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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? >=20 > 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=92s why I think we=92ll need to trim on the actual target. It could = also be that umass doesn=92t 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.=20 The SCR register bit DATA_STAT_AFTER_ERASE (bit 55) defines whether it = is '0' or '1'.=20 =20 which is less useful than I=92d hoped. This implies either that we hope = for it to be 0, then write a trivial program to read blocks and trim the = zero=92d ones, or we have to know the extents that are valid or invalid, = which is much harder=85. This suggests looking at umass and/or the SD adapter card would be = fruitful=85 Warner --Apple-Mail=_FEDB7C16-ECD3-453F-AEEE-53CC88EEDA19 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----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----- --Apple-Mail=_FEDB7C16-ECD3-453F-AEEE-53CC88EEDA19--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?127A95E9-82D7-413E-ABDB-81C5C3A027B4>