Date: Sat, 31 May 2014 10:38:49 +0200 From: Bernd Walter <ticso@cicely7.cicely.de> To: Jia-Shiun Li <jiashiun@gmail.com> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, Bernd Walter <ticso@cicely7.cicely.de>, Ian Lepore <ian@freebsd.org>, ticso@cicely.de Subject: Re: TRIM on SD cards Message-ID: <20140531083849.GJ26883@cicely7.cicely.de> In-Reply-To: <CAHNYxxMq7K1HeKYXigi8OC159uFJLTr9QCQ2=Vc-ryu0TaW7Hg@mail.gmail.com> References: <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan> <CC7D4DF1-7CE3-445C-9EB2-9CB0856E0AFA@bsdimp.com> <20140531044152.GK43976@funkthat.com> <CAHNYxxMq7K1HeKYXigi8OC159uFJLTr9QCQ2=Vc-ryu0TaW7Hg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, May 31, 2014 at 01:21:45PM +0800, Jia-Shiun Li wrote: > On Sat, May 31, 2014 at 12:41 PM, John-Mark Gurney <jmg@funkthat.com> wrote: > > Warner Losh wrote this message on Fri, May 30, 2014 at 21:55 -0600: > >> Blocks of zeros can safely be BIO_DELETEd. Why, because nonexistent blocks are, by definition, all zeros. The only time there?s a problem is when the TRIM doesn?t really TRIM? You don?t need it to be sparse at all. Zeros are zeros. > > > > Are you sure? TRIM'd space may or may not have a defined value to > > return upon read, and what happens if one of those blocks of zeros > > belongs to a file that needs those zeros to be zero? > > > > There are bits that declare if the drive returns zeros or not, so this > > would only be safe on those drives.. > > > > For the original question, the need is to keep info about written > blocks with the image it self, rather than directly issuing delete on > media. I think it is easier to > - erase all sdcard blocks before writing image, > - teach md to write sparse file, and > - teach dd to only write blocks according to info got from sparse image file. > > In current status block usage info got lost during image creation. > Zeroes do not guarantee their existence can be safely ignored. On the > other hand read from deleted block does not guarantee zeroes either. I > know little about sdcard, but ATA defines a TRIMmed block as being one > of the following behaviors on read, according to device: > > - non-deterministic read, each read *may* get different value > - deterministic read value, reads can be *any* fixed value > - deterministic read zero, reads are always zero. > > in practice at least both case 1 & 3 exist. Well Ok. I thought TRIM'ed blocks return zero and it would be possible to autodetect zero blocks in images. Anyway, this is only one part of my first mail. Sorry - my first mail wasn't very clear about this, but there are two other parts. Is there any option to TRIM a filesystem at a later point? Newfs can TRIM unused space of new filesystems and tunefs ensure TRIM for freshly emptied blocks. But what can I do when upgrading old systems? With the above I need to copy the data and newfs. I don't have to use images at all, but I do have to handle USB cardreader, unless I go another step further and setup a special environment with raw MMC/SD controller to write cards. How can I be sure that a given USB SD-reader really handles the TRIM? In my case I didn't get an error, but does it mean the blocks are really TRIM'ed? -- B.Walter <bernd@bwct.de> http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140531083849.GJ26883>