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>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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? >> >> 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. > > 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… 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. 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. Warner [-- Attachment #2 --] -----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-----help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?05005B04-1BDA-4242-946B-28D0DA069A42>