Date: Sat, 31 May 2014 00:37:49 -0500 From: Jim Thompson <jim@netgate.com> To: John-Mark Gurney <jmg@funkthat.com> Cc: Ian Lepore <ian@freebsd.org>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, Bernd Walter <ticso@cicely7.cicely.de>, "ticso@cicely.de" <ticso@cicely.de> Subject: Re: TRIM on SD cards Message-ID: <54DF962E-4A84-4309-ABCE-DB2DA12DAE0A@netgate.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 May 30, 2014, at 11:41 PM, John-Mark Gurney <jmg@funkthat.com> wrote:
>=20
> Warner Losh wrote this message on Fri, May 30, 2014 at 21:55 -0600:
>>> On May 30, 2014, at 9:00 PM, Ian Lepore <ian@FreeBSD.org> wrote:
>>>=20
>>>> 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's one of the reasons why I recently mentioned a desire for
>>> a /dev/ones to go with /dev/zero as a way of pre-init'ing an image to be=
>>> more friendly to flash media. The idea was not well-received by other
>>> freebsd folks.
>>>=20
>>> Maybe if the image was sparse, dd could tell the difference between an
>>> missing segment and a segment populated with zeroes and do a DELETE for
>>> missing data. I never do the image creation thing, I mostly tend to use=
>>> nfsroot and at $work we use tar to copy files to sdcards with a usb
>>> burner rather than preformatting images into files.
>>=20
>> Blocks of zeros can safely be BIO_DELETEd. Why, because nonexistent block=
s 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 z=
eros.
>=20
> 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?
>=20
> There are bits that declare if the drive returns zeros or not, so this
> would only be safe on those drives..
Since time immortal (23:59:59 31 Dec 1969), or at least 1978 or so, the file=
system has supported the idea of sparse files. =20
=46rom the iPad, so no error checking or indentation...
#include <stdio.h>
#include <sys/stat.h>
main()
{
int fd;
struct stat st =3D {0};
fd =3D open("foo", 2);
lseek(fd, 1024*1024, SEEK_SET);
write(fd, '\0', 1);
fstat(fd,&st);
if (st.st_blocksize * st.st_blocks < st.st_size)
printf("file is sparse\n);
close(fd);
exit(0);
}
Unix doesn't zero the blocks on the free list. This is the same. TRIM just t=
ells the drive that the block is free. The file system already knows.=20
The above will fail if foo exists and is at least 1MB in size. Sorry.=20
Jim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54DF962E-4A84-4309-ABCE-DB2DA12DAE0A>