Date: Sat, 31 May 2014 12:44:35 -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: <0A74DD39-7C54-4F09-A4B9-623A9BD25E2A@bsdimp.com> In-Reply-To: <CAJ-Vmom_v1Y1Lt2ne7CLGvnSVLT0YE=MUj7JcoHF31aWy_9pEg@mail.gmail.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>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_834E1923-378E-480B-87B5-C62E17ACD6C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 31, 2014, at 12:06 PM, Adrian Chadd <adrian@freebsd.org> wrote: > 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. Except why have an extra step when all that metadata is encoded in the = filesystem itself? Warner --Apple-Mail=_834E1923-378E-480B-87B5-C62E17ACD6C8 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 iQIcBAEBCgAGBQJTiiMTAAoJEGwc0Sh9sBEA8AQP/RiQ71lHsceYFND/HoV9uBRf vfYHXVMZHrO6JYG0DCam81jhPpTaRwRHPw9NdWRwOLrjHiwPB/amTmIxfMifpu1R zTbS2MMJqZUn6/lL0nQy4eUeOD6Uo7F1t09G5dMJONFAFD0sr9QgSVeHmz+TgkFf 9sjzQVP6NPya3tCrXnhNIXn2sAIcycPXPc1j+7c9WSi1042KdckDxDcBkR4OB2Vv Kf5P5ODf4/5uMzB6PnC8So5oDszKVwIFrLzfg2LUWPZnQ/eiPR/Nc8+IpcTaOEd6 TlzkOA4chLEYxo5W1+Yj6wUsMKDneUFJtv5po3eCTNtn76bgeIo5vOMffsyN96VQ SeVLH/XYT/7oRhycrUB3Fbisj7m+iOUsxhjn9N95R+0JLaJ2ZbgWSBH2gqZuquCf 6Is6oGIGVgUzZ8a+GSH62tYjARLPgltpth0YMW+UbWjwnY6w1JZgAvJtPjSu2Dc0 SzyXZWZyv2syYX/d0f71Ah+Ngi93UWaws8bhEQ5ya/WUY0o/jYYxA8jOldejldbX vE+qQg/mEeoP7Mk5XS/jD+5C0z6fAuq6EZ//Q0HqtXc85l79+AxIEp5hfL/bmKve KV6fdus6aDwFUeLCCmshSTzQ1TnnGQvOeJfIL6dNkyjxg01+0vL6cpcbT1/jWTcv TDh0Z/+ntnF5j96xs1qj =+wkZ -----END PGP SIGNATURE----- --Apple-Mail=_834E1923-378E-480B-87B5-C62E17ACD6C8--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0A74DD39-7C54-4F09-A4B9-623A9BD25E2A>