From owner-freebsd-arm@FreeBSD.ORG Sat May 31 16:45:36 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 BE4491B1 for ; Sat, 31 May 2014 16:45:36 +0000 (UTC) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) (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 8BED6275C for ; Sat, 31 May 2014 16:45:36 +0000 (UTC) Received: by mail-pa0-f50.google.com with SMTP id fb1so2758695pad.37 for ; Sat, 31 May 2014 09:45:30 -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=Xj7DPmmaoZep0mUON6hHIh4TSafOcOZS3egcah0qh3g=; b=iY5t/wS43CUJrEXVBA+T+wS4RGfbqADmDiBCUWvQvPcKNGUhNart3QtgwtytgJ4svi UNgpxLJER5cQZ6n2OsNHfPgAUUclxUdIlOhxyyO+YpFYOwQdS3R8CJLeiwQ/3TVoUnrp qb/AKr9XgkPMwFBWf65B9iuncDwZLPfvoV4hQv5mhJPu8IXb4Da6iKXauCdfNGf88Tb0 PzGQbj2XMnzazD4P3cZyAt4aVpcY3Q+do1jCnpThPGm9YYsl60oNK9pcy4Nj4b3NmSyo GRZtrrxuAtdI8Tl25Fg6dVT6egBOH4d/YAQPzPxwP/Sx9NlNfr7hbmKKHKcH0HonYzhK ctgg== X-Gm-Message-State: ALoCoQlX0saX6bIBKujjKD5JNoYZdzhZu38qgugLXEFKqfwqT+51QmU9CkQAWhfJDx8EXL9Sh0OP X-Received: by 10.68.237.33 with SMTP id uz1mr27875566pbc.76.1401554730460; Sat, 31 May 2014 09:45:30 -0700 (PDT) Received: from lgmac-rtangirala.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id xk3sm12061442pbb.65.2014.05.31.09.45.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 31 May 2014 09:45:29 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_85874F1D-B829-4757-9B82-F7A7D14631F0"; 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: <20140531102305.GK26883@cicely7.cicely.de> Date: Sat, 31 May 2014 10:45:30 -0600 Message-Id: <05005B04-1BDA-4242-946B-28D0DA069A42@bsdimp.com> References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <20140531102305.GK26883@cicely7.cicely.de> To: ticso@cicely.de X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm@FreeBSD.org, Bernd Walter , 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 16:45:36 -0000 --Apple-Mail=_85874F1D-B829-4757-9B82-F7A7D14631F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 31, 2014, at 4:23 AM, Bernd Walter = wrote: > On Fri, May 30, 2014 at 09:00:09PM -0600, Ian Lepore wrote: >> On Sat, 2014-05-31 at 02:43 +0200, Bernd Walter wrote: >>> It seems SD cards support a delete command, which FreeBSD supports >>> with the mmcsd driver. >>> newfs and tunefs support TRIM in that new filesystems are trim'ed >>> and the filesystems automatically trim free'ed blocks. >>> So far so good. >>> On the practical side with SD based ARM you don't write filesystems >>> directly via mmcsd. >>> We either create an image, which id dd'ed onto SD or in some cases >>> we use an USB SD drive. >>> With dd the unused blocks are written as well, which effectively >>> hurts by writing data. >>> Is there some kind of dd, which actually don't write zero blocks, >>> or even better does a trim call for them? >>=20 >> I don't think dd can safely do that. If it finds a block of zeroes = on >> the input side, how does it know it's okay to do a DELETE for those >> (which sets the block to all-bits-on on most flash media). Maybe = it's >> important for that data to really be zero; dd doesn't know. >=20 > That 1 bit thing is true for raw flash media. > A amanged NAND flash device simply unmaps a logical block from = physical > storage. > This is similar to having holes in an ufs file, which per definition > returns zero when reading a hole range. > However from reading the thread it is not save to assume managed flash > devices return zero blocks when reading TRIM'ed space. 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. 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. Warner --Apple-Mail=_85874F1D-B829-4757-9B82-F7A7D14631F0 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 iQIcBAEBCgAGBQJTigcqAAoJEGwc0Sh9sBEArVQQAI+QilFKU6INLQEbz+ikn82H zOm2aVPf3VrYXjokf9nbUuk2/5G2330MmdQDzJ/enhCon4l2UF/5L7yTeR1OLGCI O9+/cFq9umlHgKwch+CFUhL1EAwrtou21/Z9CAzxEaoLuMs7m1mR0jntCGcuUHrh Un5dzQclcPYDp3v32vjNnNvEGzNvK1fsmNdY07zUwZCj8gm3aZJkulD8Txy3lJ7W KyAA1Xh+IXQ+U7LSYkVIt8NrKYEMozU0oZ6PCBuakpDif9PiPeB/pY+TpYP/A9vM cpC4FdTkIjUxnzIWSC1u6mNuUvnLKJuOhtwDREO4r4R1Nu6EDMIKi+DriU3mvWfe v0AqYWEx6QvJQJq+79Pdk/7LCPwZB7Fl9mx7xcEidortFfCPlulORLjieaH1rUlf 1ipaPOUAybXV6W2oezneo1xm0uIj7BKEt+chM6Gij/zcxTZg5b3unNnRBohrdHlm /sbMGdl/kVr8ll+HrESdbwqJ/ttSAN7QYk5YKveC+PR1pO3i2Ndy6/HIacSrW6P/ gt499zrgDUtMTExMx3SmgIqvq3CtAhUCmtk0RFyGy84JmGq3DWoaMkOCG91i1D06 QJ9Cph+duV0ykudw5G06oayOzuasNDjVf1JOLN8gx5zvD4ATJ6+MGo8AkOnRY0FK Ie6ZTlM+S8i7QXLhaYXF =ybKK -----END PGP SIGNATURE----- --Apple-Mail=_85874F1D-B829-4757-9B82-F7A7D14631F0--