Date: Sat, 31 May 2014 10:45:30 -0600 From: Warner Losh <imp@bsdimp.com> To: ticso@cicely.de Cc: freebsd-arm@FreeBSD.org, Bernd Walter <ticso@cicely7.cicely.de>, Ian Lepore <ian@FreeBSD.org> Subject: Re: TRIM on SD cards Message-ID: <05005B04-1BDA-4242-946B-28D0DA069A42@bsdimp.com> In-Reply-To: <20140531102305.GK26883@cicely7.cicely.de> References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <20140531102305.GK26883@cicely7.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <ticso@cicely7.cicely.de> = 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?05005B04-1BDA-4242-946B-28D0DA069A42>