Date: Sat, 31 May 2014 12:49:28 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Warner Losh <imp@bsdimp.com> 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: <CAJ-Vmokq6fYg%2Bj__73r-57zOCpEXg2SZ8BgAJOM0tAG8RYFFrQ@mail.gmail.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
On 31 May 2014 11:44, Warner Losh <imp@bsdimp.com> wrote: > > 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 geo= metry was important to the BIOS, so we made our images as tar balls. We the= n 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=E2=80=A6 I = never have liked DD for creating images, even when LBAs ruled the day becau= se you=E2=80=99d always have to grow/shrink the FS afterwards. The only adv= antage it had was it was easy=E2=80=A6 Perhaps it is time to go back to tha= t model? The alternative that wouldn=E2=80=99t suck too bad would be to cre= ate variable sized images based on how much data was actually present and e= nsure there are no holes (or minimal holes) in the filesystem. >>>>> >>>>> Hmmm, if we know WHAT filesystem we=E2=80=99re 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 di= fferent kinds of TRIMs and the various translation layers we have, that mig= ht be the most robust. >>>> >>>> Having makefs spit this out would be rather useful. >>> >>> I=E2=80=99m not sure it would be. Any writes to the FS after you create= it would invalidate the list=E2=80=A6 Far easier to have fsck do it for yo= u 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 fi= lesystem itself? Cool, so how do we do this? Teach a dd like tool about FFS? :P -a
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmokq6fYg%2Bj__73r-57zOCpEXg2SZ8BgAJOM0tAG8RYFFrQ>