Date: Sat, 31 May 2014 11:06:31 -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-Vmom_v1Y1Lt2ne7CLGvnSVLT0YE=MUj7JcoHF31aWy_9pEg@mail.gmail.com> In-Reply-To: <C6388C10-C534-4141-B44C-1EEB29493A05@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 fi= les. There was so much variation between CF makers and at the time CF geome= try 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 ac= tually there, put boot blocks on it then extract the tarball=E2=80=A6 I ne= ver have liked DD for creating images, even when LBAs ruled the day because= you=E2=80=99d always have to grow/shrink the FS afterwards. The only advan= tage it had was it was easy=E2=80=A6 Perhaps it is time to go back to that = model? The alternative that wouldn=E2=80=99t suck too bad would be to creat= e variable sized images based on how much data was actually present and ens= ure there are no holes (or minimal holes) in the filesystem. >>> >>> Hmmm, if we know WHAT filesystem we=E2=80=99re dealing with, then we co= uld 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 e= nsure we start out with a nicely trimmed FS. Given the vagaries of the diff= erent 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=E2=80=99m not sure it would be. Any writes to the FS after you create i= t would invalidate the list=E2=80=A6 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. -a
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmom_v1Y1Lt2ne7CLGvnSVLT0YE=MUj7JcoHF31aWy_9pEg>