Date: Sat, 31 May 2014 15:09:11 -0600 From: Warner Losh <imp@bsdimp.com> To: John-Mark Gurney <jmg@funkthat.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: <72D59B65-09FF-4272-A795-99DC94970F7D@bsdimp.com> In-Reply-To: <20140531195659.GP43976@funkthat.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> <20140531195659.GP43976@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_0F91549C-54DD-4668-951A-E550FE368D79 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 31, 2014, at 1:56 PM, John-Mark Gurney <jmg@funkthat.com> wrote: > Warner Losh wrote this message on Sat, May 31, 2014 at 12:51 -0600: >>=20 >> On May 31, 2014, at 12:44 PM, Warner Losh <imp@bsdimp.com> wrote: >>=20 >>>=20 >>> On May 31, 2014, at 12:06 PM, Adrian Chadd <adrian@freebsd.org> = wrote: >>>=20 >>>> 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? 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. >>>>>>>=20 >>>>>>> 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. >>>>>>=20 >>>>>> Having makefs spit this out would be rather useful. >>>>>=20 >>>>> 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... >>>>=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. >>>=20 >>> Except why have an extra step when all that metadata is encoded in = the filesystem itself? >>=20 >> looks like fsck already has a -E flag: >>=20 >> -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. >>=20 >> So maybe the answer ?it is already there? might be a better reason :) >>=20 >> Bernd, can you try this on your arm box to see what it does for your = system? >=20 > Hmm... sounds like another useful command to run on first boot, though > right now it's disabled by default... >=20 > makefs doesn't support setting the flag... I'll fix makefs, as I have > some other minor changes sitting in my tree... Putting it in makefs is approximately useless=85 Warner --Apple-Mail=_0F91549C-54DD-4668-951A-E550FE368D79 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 iQIcBAEBCgAGBQJTikT4AAoJEGwc0Sh9sBEArjEP/j8Q+NoPJ+33zx5HBSCcwueN Wqpetzp96DXyO29wdYuuH7xlwO3x78KM68phWXkjulHVx1NuDFT4CWmF5f/QNK7J Z+Cx5OC7tsiVFVB5ctkK3R0BbY/KwAKHcYSswlw6RTqLCCc23gUJs24IiScYCvkT 4ZoaaOWq3x/lTvOT0/JPOa3BpjP6tg1t3TwDAT+zSH0CzTaDgN3R8GY5kVDsYcQU 9pJTBHnYKxRQKBJWsrqmhUkTzucGZL4Y4POZVtxvPEv0okbKhT6GMMwk/njrfNSb Z0U1HnuEzz44iXzIo1app/81x2bDYmH0rUwO435YgSnD6rizKAwe0lg9sgvrIdSj YLYYUmlaSgpAncV+fsFSt3ezeUF9aYnnVW8749qhUgAS1a23aHtE7fRV2mQdBB1w JeAM/lbCfvgFP+HQWJaiHfl7TzK8NzRfWpOd0CbBNU0VF2Te+GX+mZw4/mYk1sMs t759oTznlzz1T2RjqU2KpSfkmYvusiu1qXf/4ZKtHXp2kBijbfoZQNlAhNJVPCLy Zr1hRQDQdHBlZzGcLSY8jc28A9OycvwlabcmWqmcNEdHSXD6cShRbX8SPfQ3OIUh YUI0blAuSeE3pMTAk/0MQ/kR66/+ak7QhXQscgu44m8+8PBIJHwPiABL6GJ4Zsq5 nwkQSlUAMK20VtFps8RC =CbPY -----END PGP SIGNATURE----- --Apple-Mail=_0F91549C-54DD-4668-951A-E550FE368D79--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?72D59B65-09FF-4272-A795-99DC94970F7D>