Date: Fri, 30 May 2014 20:21:54 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Ian Lepore <ian@freebsd.org> Cc: "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: <CAJ-VmonDn%2BBzR-cY_j3LMFXaqegfAiMiDB1UAKcQ-jHL23yX7g@mail.gmail.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
On 30 May 2014 20:00, 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? > > 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. > > 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. > > 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. Well, what about writing some TLV style archive format for raw images that included information like that? And then a tool to blat that sparse image TLV thing to some underlying media? That way the dd utility could recover "this could be TRIMed" from regions in the image that are stated to be TRIM-friendly. Double points if it understands things like "hey, before you dd this into this partition, it'd be really cool if you laid down this partition table first." -a
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmonDn%2BBzR-cY_j3LMFXaqegfAiMiDB1UAKcQ-jHL23yX7g>