From owner-freebsd-arm@FreeBSD.ORG Sun Jun 1 02:44:57 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B36C1FCD for ; Sun, 1 Jun 2014 02:44:57 +0000 (UTC) Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7A9C924A5 for ; Sun, 1 Jun 2014 02:44:57 +0000 (UTC) Received: by mail-pb0-f48.google.com with SMTP id rr13so3047472pbb.21 for ; Sat, 31 May 2014 19:44:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=vM1nkXEV3HWWOt5VYFWHAtCC4iMRiLoI7qeladcOCaA=; b=dP4jLgagKvOseIr0ejkX71AECVC41NMg1hWR0hnj+7ZnF+EamFWJ0lD7MWbtrfTJaA XNWOHzn0Q2mhpNazh5eu3psQVzgRprQDWZiThdDg9vOwq49KmbQKNINFb5783HFCrczC +MTs2a5b3KJ3ds4mw0VgHdKdX530yhXvTzpZlnLoQk6yTx8JZjXWxQpN0vOPRfdj4C26 epFDr3zUN5t5oaIR5aZ22avwwoq5p80N19mRVLzCu3Lida2S9KgKIXFXdHCmlqTtKKqx YIV+Qlw0W7+1ihQTvkwPwdvVqdv8WG7x0cnbC1x5qKvWEdHcF423JrMqaNIkbiPMgrOw /Qiw== X-Gm-Message-State: ALoCoQn7fSF+GO85+Rm6cYuq88ntG06Ebt+A1I6DQTo7M8TsM5wgnKzof/TDEa6Mx5KHI8MfEowL X-Received: by 10.66.180.168 with SMTP id dp8mr31191850pac.100.1401590306682; Sat, 31 May 2014 19:38:26 -0700 (PDT) Received: from lgmac-rtangirala.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id ky8sm13425470pbc.64.2014.05.31.19.38.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 31 May 2014 19:38:25 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_5CF164A9-25A1-48A0-9A6E-30BA1272342D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: TRIM on SD cards From: Warner Losh In-Reply-To: <20140601023324.GD54731@cicely7.cicely.de> Date: Sat, 31 May 2014 20:38:28 -0600 Message-Id: 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> <0A74DD39-7C54-4F09-A4B9-623A9BD25E2A@bsdimp.com> <20140601004311.GB54731@cicely7.cicely.de> <20140601023324.GD54731@cicely7.cicely.de> To: ticso@cicely.de X-Mailer: Apple Mail (2.1878.2) Cc: Bernd Walter , "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 02:44:57 -0000 --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 = 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 wrote: >>>=20 >>>>=20 >>>> On May 31, 2014, at 12:06 PM, Adrian Chadd = wrote: >>>>=20 >>>>> On 31 May 2014 10:49, Warner Losh wrote: >>>>>>=20 >>>>>> On May 31, 2014, at 11:31 AM, Adrian Chadd = wrote: >>>>>>=20 >>>>>>> On 31 May 2014 09:45, Warner Losh 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--