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>