From owner-freebsd-arm@FreeBSD.ORG Sat May 31 18:44:35 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A820A56 for ; Sat, 31 May 2014 18:44:35 +0000 (UTC) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) (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 45044229D for ; Sat, 31 May 2014 18:44:35 +0000 (UTC) Received: by mail-pb0-f43.google.com with SMTP id up15so2837547pbc.2 for ; Sat, 31 May 2014 11:44:34 -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=42UQzNBquDw5/fbN0pqc/KphYT7eN7PLB5fISmTlfaM=; b=eiJRXnOnfyio+vOdDWr9KVKpjXf/EHFclFmWZhghQYpAfC0Ik+7Ac+03yhWW39rkdM 07LSKiMwG3GYlpYRpYryOKLe9ZGvbEJse4spThuazV/Fa7Vu2TNjCSr6ktvqURx3jVHf gw1NIMNMoQCDbFRzXUm9uW7JIPrpNeygWPlT7S5MsIIrigZXBBcGQd2wc6tlkylfWyGq pwSk/IxBPzEQXgzQyiprrr2W0Tf+KFFCI2bqQPz7b5qMLUrdUndzR9wP/dBgEE/VqPq8 ykEv7dQJU8LTFLUmlI5VYg+xicvZ1TtGTQRfPHd0Vvw25+9fPPZkc3Ex2i4HS+enHeKu qayA== X-Gm-Message-State: ALoCoQnkhRvA0H1wgUs9VxShQtCExyIUo+xQG6wOVtbA45Am6DmXvKSVB1lvtPTMUsixLrgXBdzL X-Received: by 10.69.25.105 with SMTP id ip9mr28432202pbd.145.1401561874734; Sat, 31 May 2014 11:44:34 -0700 (PDT) Received: from lgmac-rtangirala.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id mt1sm12437464pbb.31.2014.05.31.11.44.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 31 May 2014 11:44:34 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_834E1923-378E-480B-87B5-C62E17ACD6C8"; 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: Date: Sat, 31 May 2014 12:44:35 -0600 Message-Id: <0A74DD39-7C54-4F09-A4B9-623A9BD25E2A@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> To: Adrian Chadd X-Mailer: Apple Mail (2.1878.2) Cc: "freebsd-arm@freebsd.org" , Bernd Walter , ticso@cicely.de, 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: Sat, 31 May 2014 18:44:35 -0000 --Apple-Mail=_834E1923-378E-480B-87B5-C62E17ACD6C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 31, 2014, at 12:06 PM, Adrian Chadd wrote: > 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=85 I never have liked DD for creating images, even when LBAs = ruled the day because you=92d always have to grow/shrink the FS = afterwards. The only advantage it had was it was easy=85 Perhaps it is = time to go back to that model? The alternative that wouldn=92t 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=92re 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=92m not sure it would be. Any writes to the FS after you create it = would invalidate the list=85 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. Except why have an extra step when all that metadata is encoded in the = filesystem itself? Warner --Apple-Mail=_834E1923-378E-480B-87B5-C62E17ACD6C8 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 iQIcBAEBCgAGBQJTiiMTAAoJEGwc0Sh9sBEA8AQP/RiQ71lHsceYFND/HoV9uBRf vfYHXVMZHrO6JYG0DCam81jhPpTaRwRHPw9NdWRwOLrjHiwPB/amTmIxfMifpu1R zTbS2MMJqZUn6/lL0nQy4eUeOD6Uo7F1t09G5dMJONFAFD0sr9QgSVeHmz+TgkFf 9sjzQVP6NPya3tCrXnhNIXn2sAIcycPXPc1j+7c9WSi1042KdckDxDcBkR4OB2Vv Kf5P5ODf4/5uMzB6PnC8So5oDszKVwIFrLzfg2LUWPZnQ/eiPR/Nc8+IpcTaOEd6 TlzkOA4chLEYxo5W1+Yj6wUsMKDneUFJtv5po3eCTNtn76bgeIo5vOMffsyN96VQ SeVLH/XYT/7oRhycrUB3Fbisj7m+iOUsxhjn9N95R+0JLaJ2ZbgWSBH2gqZuquCf 6Is6oGIGVgUzZ8a+GSH62tYjARLPgltpth0YMW+UbWjwnY6w1JZgAvJtPjSu2Dc0 SzyXZWZyv2syYX/d0f71Ah+Ngi93UWaws8bhEQ5ya/WUY0o/jYYxA8jOldejldbX vE+qQg/mEeoP7Mk5XS/jD+5C0z6fAuq6EZ//Q0HqtXc85l79+AxIEp5hfL/bmKve KV6fdus6aDwFUeLCCmshSTzQ1TnnGQvOeJfIL6dNkyjxg01+0vL6cpcbT1/jWTcv TDh0Z/+ntnF5j96xs1qj =+wkZ -----END PGP SIGNATURE----- --Apple-Mail=_834E1923-378E-480B-87B5-C62E17ACD6C8--