Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 31 May 2014 13:21:45 +0800
From:      Jia-Shiun Li <jiashiun@gmail.com>
To:        Warner Losh <imp@bsdimp.com>, Ian Lepore <ian@freebsd.org>,  "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, Bernd Walter <ticso@cicely7.cicely.de>, ticso@cicely.de
Subject:   Re: TRIM on SD cards
Message-ID:  <CAHNYxxMq7K1HeKYXigi8OC159uFJLTr9QCQ2=Vc-ryu0TaW7Hg@mail.gmail.com>
In-Reply-To: <20140531044152.GK43976@funkthat.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>

next in thread | previous in thread | raw e-mail | index | archive | help
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.



-Jia-Shiun



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHNYxxMq7K1HeKYXigi8OC159uFJLTr9QCQ2=Vc-ryu0TaW7Hg>