From owner-freebsd-arm@FreeBSD.ORG Sat May 31 21:16:05 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 5529BB46 for ; Sat, 31 May 2014 21:16:05 +0000 (UTC) Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) (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 1D6552E40 for ; Sat, 31 May 2014 21:16:04 +0000 (UTC) Received: by mail-pd0-f178.google.com with SMTP id v10so2109844pde.23 for ; Sat, 31 May 2014 14:16:04 -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=I1xlZouQZGVGOA0Aetjj04N4eXb+kINB/heP7RKpxH8=; b=NUovmRPNJra5efRvxmaBMlVuyKEAkn1hq/HXBmyYb92dqJ5OyltzFx+VtLnR6GOrFe XjtQiGpY4k7tous2fYA0cFD/2xbY7E9E9SE+jIi0gZIaYjvde61NaZoQeVjGbm/OEE/N Nv1mEtM4G63UHg5NiWxaLKlzMrMxogRLrAynhRO8SowSXn0XWVIO0aWUntS6HoF1sGve lvKhrUs4mKHx8ufJGri2bhOToVScgWHNVqIqY41M1TSphwNNolkzTVHw8JSOusqCv5bQ 6X1E6CtTlJ/YmDif8wSsHPLMDiTeQ9TScuEvc1eKo3BZDfpUJ9cdpSDmaCK7lWbx/Y/K Rsmg== X-Gm-Message-State: ALoCoQnX8rCu9R/cNqkXIFH7MAs5L3lhuKjEXAZeJZrH2mzI6F6oVqmfdFHnXeap1qYKcXnG48TB X-Received: by 10.68.240.5 with SMTP id vw5mr28537522pbc.113.1401570550879; Sat, 31 May 2014 14:09:10 -0700 (PDT) Received: from lgmac-rtangirala.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id wq10sm38842514pac.24.2014.05.31.14.09.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 31 May 2014 14:09:10 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_0F91549C-54DD-4668-951A-E550FE368D79"; 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: <20140531195659.GP43976@funkthat.com> Date: Sat, 31 May 2014 15:09:11 -0600 Message-Id: <72D59B65-09FF-4272-A795-99DC94970F7D@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> <0A74DD39-7C54-4F09-A4B9-623A9BD25E2A@bsdimp.com> <20140531195659.GP43976@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: Sat, 31 May 2014 21:16:05 -0000 --Apple-Mail=_0F91549C-54DD-4668-951A-E550FE368D79 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 31, 2014, at 1:56 PM, John-Mark Gurney wrote: > 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... Putting it in makefs is approximately useless=85 Warner --Apple-Mail=_0F91549C-54DD-4668-951A-E550FE368D79 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 iQIcBAEBCgAGBQJTikT4AAoJEGwc0Sh9sBEArjEP/j8Q+NoPJ+33zx5HBSCcwueN Wqpetzp96DXyO29wdYuuH7xlwO3x78KM68phWXkjulHVx1NuDFT4CWmF5f/QNK7J Z+Cx5OC7tsiVFVB5ctkK3R0BbY/KwAKHcYSswlw6RTqLCCc23gUJs24IiScYCvkT 4ZoaaOWq3x/lTvOT0/JPOa3BpjP6tg1t3TwDAT+zSH0CzTaDgN3R8GY5kVDsYcQU 9pJTBHnYKxRQKBJWsrqmhUkTzucGZL4Y4POZVtxvPEv0okbKhT6GMMwk/njrfNSb Z0U1HnuEzz44iXzIo1app/81x2bDYmH0rUwO435YgSnD6rizKAwe0lg9sgvrIdSj YLYYUmlaSgpAncV+fsFSt3ezeUF9aYnnVW8749qhUgAS1a23aHtE7fRV2mQdBB1w JeAM/lbCfvgFP+HQWJaiHfl7TzK8NzRfWpOd0CbBNU0VF2Te+GX+mZw4/mYk1sMs t759oTznlzz1T2RjqU2KpSfkmYvusiu1qXf/4ZKtHXp2kBijbfoZQNlAhNJVPCLy Zr1hRQDQdHBlZzGcLSY8jc28A9OycvwlabcmWqmcNEdHSXD6cShRbX8SPfQ3OIUh YUI0blAuSeE3pMTAk/0MQ/kR66/+ak7QhXQscgu44m8+8PBIJHwPiABL6GJ4Zsq5 nwkQSlUAMK20VtFps8RC =CbPY -----END PGP SIGNATURE----- --Apple-Mail=_0F91549C-54DD-4668-951A-E550FE368D79--