Date: Sat, 31 May 2014 12:51:42 -0600 From: Warner Losh <imp@bsdimp.com> To: Adrian Chadd <adrian@freebsd.org> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, Bernd Walter <ticso@cicely7.cicely.de>, ticso@cicely.de, Ian Lepore <ian@freebsd.org> Subject: Re: TRIM on SD cards Message-ID: <B2EEF112-2AE3-401E-84CF-3E28A7F69599@bsdimp.com> In-Reply-To: <0A74DD39-7C54-4F09-A4B9-623A9BD25E2A@bsdimp.com> References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <20140531102305.GK26883@cicely7.cicely.de> <05005B04-1BDA-4242-946B-28D0DA069A42@bsdimp.com> <CAJ-Vmom=r9FA_HWLTjgThSZPncGw3dkCknNGCEpd=F39AJN8ww@mail.gmail.com> <C6388C10-C534-4141-B44C-1EEB29493A05@bsdimp.com> <CAJ-Vmom_v1Y1Lt2ne7CLGvnSVLT0YE=MUj7JcoHF31aWy_9pEg@mail.gmail.com> <0A74DD39-7C54-4F09-A4B9-623A9BD25E2A@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_283F729B-7F4B-4D0E-B4A0-C5CAB0496CBD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 31, 2014, at 12:44 PM, Warner Losh <imp@bsdimp.com> wrote: >=20 > On May 31, 2014, at 12:06 PM, Adrian Chadd <adrian@freebsd.org> wrote: >=20 >> On 31 May 2014 10:49, Warner Losh <imp@bsdimp.com> wrote: >>>=20 >>> On May 31, 2014, at 11:31 AM, Adrian Chadd <adrian@freebsd.org> = wrote: >>>=20 >>>> On 31 May 2014 09:45, Warner Losh <imp@bsdimp.com> wrote: >>>>=20 >>>>> 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=85 I never have liked DD for creating images, even when LBAs = ruled the day because you=92d always have to grow/shrink the FS = afterwards. The only advantage it had was it was easy=85 Perhaps it is = time to go back to that model? The alternative that wouldn=92t 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. >>>>>=20 >>>>> Hmmm, if we know WHAT filesystem we=92re 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. >>>>=20 >>>> Having makefs spit this out would be rather useful. >>>=20 >>> I=92m not sure it would be. Any writes to the FS after you create it = would invalidate the list=85 Far easier to have fsck do it for you any = time you need it... >>=20 >> Sure, but it'd be part of a larger scale image creation and writing >> tool. That way you could ship images that had the sparseness bits in >> them and the tool + growfs can TRIM as appropriate on the installing >> media. >=20 > Except why have an extra step when all that metadata is encoded in the = filesystem itself? looks like fsck already has a -E flag: -E Clear unallocated blocks, notifying the underlying device = that they are not used and that their contents may be discarded. = This is useful for filesystems which have been mounted on = systems without TRIM support, or with TRIM support disabled, as = well as filesystems which have been copied from one device to = another. So maybe the answer =91it is already there=92 might be a better reason = :) Bernd, can you try this on your arm box to see what it does for your = system? Warner --Apple-Mail=_283F729B-7F4B-4D0E-B4A0-C5CAB0496CBD 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 iQIcBAEBCgAGBQJTiiS/AAoJEGwc0Sh9sBEAA20P/j9RBKiDQ5ifi5rU7LtUkxxa MZ5WW9QMUfOriy8JHvkCFnTMahO8/ukWmGE38SGw1+SHpleXZ5wA0gLW80ykoBaP GiE/329e5oz6PQWeUXHXK7pj3ye3IM1weSxgsnM6qnCCgvrLpKcQcdVz6TjjyLG1 XmrlILCTUegDFkL0GhsXAW3o22AJlDkRKVoIjeqhVwgTQs+e+pXm4R6A6e/uBxTI poV0UyoTcoj9FolzdyPQbfU74uOE/qyojFelbHfLdNGrNLkfmm1mQMELrVP0Uq5R kHnhH6ZWqu5gCa1/N5To/JlXftPCPrh933wsB3KvWGmv7exbbR8PSkzYR53oBFd9 GodZjvXdNxeJXnXUCgkhVxPpB4ixQctT1lHwyrJX5rjKkcktJQQhmKCOkMicjxyS z4fVaUDmSKTlKvZAwGllda8gu7ipnyqk6pyWnlOcVJ+uLXgSnqjyNuf+bptkkY/J xyxz3Aa00zzb6TFhhecsB1wfGN7LY6ogh5E03zpT9WO6UquLTNQC7G4cXZpOzrfo eXRx+KMNC2Jn+cOO6VhK1wIttG2G294pBsLgmwcPLUMqmBXJBqxrIYudPHWbevBa BepJgo5rJlYKYWx2nhzEF9zLFs/lrIO8c2HqEpCagkQLUyfSxncnISwqkxjzOLvo Zl/pphVYXS3cELNrMhhc =UNSX -----END PGP SIGNATURE----- --Apple-Mail=_283F729B-7F4B-4D0E-B4A0-C5CAB0496CBD--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B2EEF112-2AE3-401E-84CF-3E28A7F69599>