From owner-freebsd-arm@FreeBSD.ORG Sun Jun 1 02:37:24 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 8F02FF1A for ; Sun, 1 Jun 2014 02:37:24 +0000 (UTC) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) (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 55A3C2415 for ; Sun, 1 Jun 2014 02:37:23 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id rd3so3044440pab.29 for ; Sat, 31 May 2014 19:37:17 -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=wJmsgiRE1vGFf4LquzLAKcL/cd+rPJu8EPh7H8J/EWk=; b=Sr6sg28Z77yljOc6MtYuFpTIjRq+LHn56crXqygqfq7M6WnH16dd/pB8YRjILjeYjH FAMECVyeffRmy4qdBIjqao/W2WCDQiSQCfWMnMWR4ARvIMHIDFi2Gps2khFbuA086cbw BElcw0S97lFvsxZRNCLfYRaOYXFrlMCibG1IVx7rv04V90vcDjQwBiJNWnxvT/+Q6FDH +goGwGttVrLrJImymdC+1hRZgJJwgbo8FAXB82sRMt0QxrK/zbjqDC3JKYRlLx40AeTm uoVE81X168EPl4VrR6dOSXh7Vpq9qj0I/MtZdZ2LVED36xqkZmDyEJ771XRhmcSPDm1+ NijQ== X-Gm-Message-State: ALoCoQkJXGVhrFYDky6ldFsWLe35ctkbrYqBY9Z9KZt5lEGIfTLYcDtG+MDLETG3+Pg8Z3ZrRfDm X-Received: by 10.66.248.65 with SMTP id yk1mr30662375pac.38.1401590237205; Sat, 31 May 2014 19:37:17 -0700 (PDT) Received: from lgmac-rtangirala.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id yx3sm13472569pbb.6.2014.05.31.19.37.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 31 May 2014 19:37:16 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_B6266CF5-BA0D-4F15-99A9-3D9AF060C655"; 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: <20140601002603.GQ43976@funkthat.com> Date: Sat, 31 May 2014 20:37:18 -0600 Message-Id: References: <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> <20140531195659.GP43976@funkthat.com> <72D59B65-09FF-4272-A795-99DC94970F7D@bsdimp.com> <20140601002603.GQ43976@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1878.2) Cc: Bernd Walter , "freebsd-arm@freebsd.org" , Ian Lepore , ticso@cicely.de 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:37:24 -0000 --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 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 = 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 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 >>> 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--