Date: Sat, 31 May 2014 20:37:18 -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: <E525A3BE-8C98-41A2-A04F-3457CB0E361C@bsdimp.com> In-Reply-To: <20140601002603.GQ43976@funkthat.com> References: <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> <72D59B65-09FF-4272-A795-99DC94970F7D@bsdimp.com> <20140601002603.GQ43976@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_B6266CF5-BA0D-4F15-99A9-3D9AF060C655 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 31, 2014, at 6:26 PM, John-Mark Gurney <jmg@funkthat.com> wrote: > Warner Losh wrote this message on Sat, May 31, 2014 at 15:09 -0600: >>=20 >> On May 31, 2014, at 1:56 PM, John-Mark Gurney <jmg@funkthat.com> = wrote: >>=20 >>> 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... >>=20 >> Putting it in makefs is approximately useless? >=20 > How else can you use makefs to generate a FS that will use trim if > makefs doesn't set the _TRIM flag? Or do you mean you can set it on > a live system w/ tunefs? If so, then why don't we remove the label > option, since that too can be set by tunefs... Doh! I thought you meant the -E option, not the -t option :) Warner --Apple-Mail=_B6266CF5-BA0D-4F15-99A9-3D9AF060C655 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 iQIcBAEBCgAGBQJTipHeAAoJEGwc0Sh9sBEARBYQANRNIdr/+ivnRJAKTBE3PgEl vaYjavx4ZweyB7syQuFzObSaooX+8INMoodJKZHE8YXR5yeO2qasNTXlN/OrGHL5 TTqAs+D6uiKe6AoG9/2s38nwRx5C6jh30xd3iC23I3ZyjaSdLq2M4/zeoC5ej2qp SPU4oiS+/twi1CCe7jlg/PqlGh6eP6Y5uBXU51BWWRwwZzNhZg7Gm7YGyzcrO72f XFJy/ncEylCKn+23N0oPTKYnMesa0+DWQSDOr69VYDnb+x/CGWgNX9VSEEmX0eO2 vC9/azNoR3U3qmw3A+By2klHwhoRFXzx5WOnqKGaUgYkqO0Zvc+hbQKmq4UqD+28 xkx+KwH4Z4U0phECSbTtuwG5gLR/yQEWWkDIJfK5ii8LZ6q6DLssTNjvQ72jBFEG 3bd10e3MOfypFTCqapHG+F8una67QxhXiBTaifcs/mrna09/cY6zxfFh55oowNmw fgILJacFWeWBkONnmGzZJtv9tG89ikwEJaNGAuHoBnzkNscpfAgGjZuwkEIZ743z atKskRSXrO8fB44jn1hV+v+KQR9dMfAC2wit80y5uZWVI5ZL98eiSOvkNalF7VwB rY66sBihO68sH7fhjZeSvzkzREahIWB1ZcpH/WLypxRi43BABcHlQXMR8Dnu4IbZ exdA4znStFDtmSoxQcPS =qjOr -----END PGP SIGNATURE----- --Apple-Mail=_B6266CF5-BA0D-4F15-99A9-3D9AF060C655--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E525A3BE-8C98-41A2-A04F-3457CB0E361C>