Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 30 May 2014 21:55:02 -0600
From:      Warner Losh <imp@bsdimp.com>
To:        Ian Lepore <ian@FreeBSD.org>
Cc:        freebsd-arm@FreeBSD.org, Bernd Walter <ticso@cicely7.cicely.de>, ticso@cicely.de
Subject:   Re: TRIM on SD cards
Message-ID:  <CC7D4DF1-7CE3-445C-9EB2-9CB0856E0AFA@bsdimp.com>
In-Reply-To: <1401505209.20883.34.camel@revolution.hippie.lan>
References:  <20140531004306.GI26883@cicely7.cicely.de> <1401505209.20883.34.camel@revolution.hippie.lan>

next in thread | previous in thread | raw e-mail | index | archive | help

--Apple-Mail=_9C453B3F-2FC5-4690-8559-A26EA57512CE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On May 30, 2014, at 9:00 PM, Ian Lepore <ian@FreeBSD.org> 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'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.

Blocks of zeros can safely be BIO_DELETEd. Why, because nonexistent =
blocks are, by definition, all zeros. The only time there=92s a problem =
is when the TRIM doesn=92t really TRIM=85 You don=92t need it to be =
sparse at all. Zeros are zeros.

Warner


> -- Ian
>=20
>> Is there a tool to trim a filesystem after creation?
>> Ok - even then there is the option to directly newfs on the SD card.
>> But in any case I need to be able to issue trim requests to the card.
>> It seems there is support in our da driver, but will it be =
transported
>> to the USB reader and even if - how can I find out if my reader =
actually
>> supports trim commands?
>> A newfs -t -E with my older transcend multireader and a new class10
>> Intenso micro-SD issues no error.
>> But is it save to assume the card actually got trim'ed?
>>=20
>> Trim is enabled on the filesystem, but not shown in mount list:
>> [189]gw1# tunefs -t enable /dev/da0
>> tunefs: issue TRIM to the disk remains unchanged as enabled
>> [190]gw1# mount /dev/da0 /mnt
>> [191]gw1# mount | grep mnt
>> /dev/da0 on /mnt (ufs, local, soft-updates)
>> FreeBSD gw1.cicely.de 10.0-STABLE FreeBSD 10.0-STABLE #0: Thu Apr 17 =
11:47:45 CEST 2014     =
ticso@gw1.cicely.de:/usr/obj/home/builder/gw1/10/sys/GW1  i386
>>=20
>=20
>=20
> _______________________________________________
> freebsd-arm@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"


--Apple-Mail=_9C453B3F-2FC5-4690-8559-A26EA57512CE
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJTiVKWAAoJEGwc0Sh9sBEA1IcP/jjkqOFlK8eMf9F3Hx3GE5qi
cggpcYAJfd3afUV599L55dAhM7aEJSvJRyb9jwb57MtJhpJlmv46kV/fKpfgPwpR
DZRfm7G/kBbW6XWHEiKZw3BXLiXgvNRrco4gPpfCINeG/oKXq99ZGdoQ5aXH8Gys
zxWtFc72Q5i56NXwIcZH9W2PGA0+ygmv8pxVxjpXl3OIYdC4PyzsLHvmdvCrP/XO
PXD6F1p2vEc3NXPdkgbDbHyfZYiLmi3umfkQVYWLsR4WYaA/QA0v+V9Z5/VBHJ5y
LTfnhrAcxqUNT8cVJwqEMxsDDk8TnHcmMv6xT5s0CqHY00XZ2dDp4MXdzJPpehgj
59YRn/L+OaNPGoWKLSQu2cmbXU1JgbRhUnLHqUrzgXvJvAQnIrMgnRpMdX88J6sP
dyjjiJWaYBR9m64USz1ZVplhbxeLXiebsks91G5AG2iUZC+51fNz9LDbJ1C24qaT
JdfdF7VZ/M8QaGtvf4u75P+J6TJjsKje/jp112Sql5beQWRRFLQwiH0e6pj8809w
/XoR6EeuRV4Qqd6/LUTxjYvzJRJrQqQn7TOo1h5kbsPFkjQXXu+0fqPK5Ua3nizI
C0HSP0WxE/Wb83Bs00WOV3/MVJ8+OCj6f5BtO560UwFH04rsgP2YpqkzH8vZoHtB
twDnUZcFnsGQJvaIgWqx
=p8J5
-----END PGP SIGNATURE-----

--Apple-Mail=_9C453B3F-2FC5-4690-8559-A26EA57512CE--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CC7D4DF1-7CE3-445C-9EB2-9CB0856E0AFA>