Date: Sat, 31 May 2014 12:56:59 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: Warner Losh <imp@bsdimp.com> Cc: Bernd Walter <ticso@cicely7.cicely.de>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, Ian Lepore <ian@freebsd.org>, ticso@cicely.de Subject: Re: TRIM on SD cards Message-ID: <20140531195659.GP43976@funkthat.com> In-Reply-To: <B2EEF112-2AE3-401E-84CF-3E28A7F69599@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> <B2EEF112-2AE3-401E-84CF-3E28A7F69599@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh wrote this message on Sat, May 31, 2014 at 12:51 -0600:
>
> On May 31, 2014, at 12:44 PM, 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 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?
>
> 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 ?it is already there? might be a better reason :)
>
> Bernd, can you try this on your arm box to see what it does for your system?
Hmm... sounds like another useful command to run on first boot, though
right now it's disabled by default...
makefs doesn't support setting the flag... I'll fix makefs, as I have
some other minor changes sitting in my tree...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140531195659.GP43976>