Date: Sat, 31 May 2014 11:48:19 -0600 From: Ian Lepore <ian@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-arm@FreeBSD.org, Bernd Walter <ticso@cicely7.cicely.de>, ticso@cicely.de Subject: Re: TRIM on SD cards Message-ID: <1401558499.20883.44.camel@revolution.hippie.lan> In-Reply-To: <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> <05005B04-1BDA-4242-946B-28D0DA069A42@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2014-05-31 at 10:45 -0600, Warner Losh wrote: > On May 31, 2014, at 4:23 AM, Bernd Walter <ticso@cicely7.cicely.de> wro= te: >=20 > > 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 physic= al > > 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 flas= h > > devices return zero blocks when reading TRIM'ed space. >=20 > One of the things that I did for images years ago was compressed tar fi= les. There was so much variation between CF makers and at the time CF geo= metry was important to the BIOS, so we made our images as tar balls. We t= hen 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 bec= ause you=92d always have to grow/shrink the FS afterwards. The only advan= tage it had was it was easy=85 Perhaps it is time to go back to that mode= l? The alternative that wouldn=92t suck too bad would be to create variab= le sized images based on how much data was actually present and ensure th= ere are no holes (or minimal holes) in the filesystem. >=20 > Hmmm, if we know WHAT filesystem we=92re dealing with, then we could pe= rhaps enhance fsck and/or growfs to BIO_DELETE all the blocks that it kno= ws are free, which would be a useful, data-driven approach that could ens= ure we start out with a nicely trimmed FS. Given the vagaries of the diff= erent kinds of TRIMs and the various translation layers we have, that mig= ht be the most robust. >=20 > Warner >=20 I wouldn't at all mind an fsck or growfs option or a standalone tool that would issue deletes for unused blocks on an existing filesystem. I have several big SSDs on this system and I had no TRIM support for a long time, so there are lots of blocks on the drives that bogusly look used to the onboard block management code. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1401558499.20883.44.camel>