Date: Sat, 31 May 2014 20:38:28 -0600 From: Warner Losh <imp@bsdimp.com> To: ticso@cicely.de Cc: Bernd Walter <ticso@cicely7.cicely.de>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, Ian Lepore <ian@freebsd.org> Subject: Re: TRIM on SD cards Message-ID: <D9FA86EF-CB5F-4AAB-9F38-406A35412DDE@bsdimp.com> In-Reply-To: <20140601023324.GD54731@cicely7.cicely.de> 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> <20140601004311.GB54731@cicely7.cicely.de> <20140601023324.GD54731@cicely7.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_5CF164A9-25A1-48A0-9A6E-30BA1272342D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 31, 2014, at 8:33 PM, Bernd Walter <ticso@cicely7.cicely.de> = wrote: > On Sun, Jun 01, 2014 at 02:43:11AM +0200, Bernd Walter wrote: >> On Sat, May 31, 2014 at 12:51:42PM -0600, Warner Losh wrote: >>>=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 >> Oh damn - I should have looked into the fsck manpage. >> This is great. >> I've put it on my TODO list for next week. >=20 > Seems to be a rather new feature. > At least my 1 month old stable system don't have this feature. > At least this explains why I didn't spot it - I thought to have looked > into fsck manpage, but wasn't sure. That=92s because it is in the fsck_ffs man page, not the fsck man page. Warner --Apple-Mail=_5CF164A9-25A1-48A0-9A6E-30BA1272342D 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 iQIcBAEBCgAGBQJTipIkAAoJEGwc0Sh9sBEAYz4P/A7EZ32DUV95zxwrU9Xuu0XS 2UqEOTFDdobGfjgh7m1Ij2WtWYgVnpeLTOUE5qjexg1DKEf+GIbjRAkr0zBBRqdZ e4lSrx9QFczwyOMOJmRAx7tcMVvYu/mQUaAco1QgtccHCadvcy5/B7jh/29/tM8r n0vpxEejlty9NKBYZvGBgmDcey6FkW+4xu7mNpajohcvmSXhMShEr9iLvkDh62JF CgMDe9/nLzPe7AteVrvBsvGn2KAiYerulq4IYaN7HN9HmTY/UJKJG5s93fLjEejQ pKs3JhKIipz5r67M0+6BDQjAORuBoupCmdDjCy2nhetioqTbCozVfkPUwlmH2I4r Rf3fPIXzXWTBdIZ4k0LoekKAKJJjRyE3DYLqReu/zwgIrdUOTLWFTzEE1uMCejBs KNs6bN2V3s9UfsylLx42QFHC7WJU0/DZIrpT2yXX/9ME1PF2IB9K8JqZlESyJbt+ rit/IUC9q8jZnV39hg4xU0nKnZZySHs9WA5Sy8V+Is8VMgo8mI/IhsQjSgXsizqu mxrOnQbapSGuwEUCH/3NLBUhQJEIk587yJZJqdg2uH6R2Tx0ik3GniAChuonBlEe D/fV0RtV3yYqGBifF9R2rr4kVoCTk79LCYSsmU2zTOvLl3JNwUMM0NCaxvInCWt6 eDAaMz2TEg5ozk+XcmeN =QMsK -----END PGP SIGNATURE----- --Apple-Mail=_5CF164A9-25A1-48A0-9A6E-30BA1272342D--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D9FA86EF-CB5F-4AAB-9F38-406A35412DDE>