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>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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: >> >> On May 31, 2014, at 11:31 AM, Adrian Chadd <adrian@freebsd.org> wrote: >> >>> On 31 May 2014 09:45, Warner Losh <imp@bsdimp.com> wrote: >>> >>>> 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… I never have liked DD for creating images, even when LBAs ruled the day because you’d always have to grow/shrink the FS afterwards. The only advantage it had was it was easy… Perhaps it is time to go back to that model? The alternative that wouldn’t 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. >>>> >>>> Hmmm, if we know WHAT filesystem we’re 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. >>> >>> Having makefs spit this out would be rather useful. >> >> I’m not sure it would be. Any writes to the FS after you create it would invalidate the list… Far easier to have fsck do it for you any time you need it... > > 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 [-- Attachment #2 --] -----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-----help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0A74DD39-7C54-4F09-A4B9-623A9BD25E2A>