Date: Fri, 30 Nov 2018 10:04:21 -0800 From: Maxim Sobolev <sobomax@freebsd.org> To: rgrimes@freebsd.org Cc: Warner Losh <imp@bsdimp.com>, Alexey Dokuchaev <danfe@freebsd.org>, Eugene Grosbein <eugen@grosbein.net>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, steven.hartland@multiplay.co.uk, svn-src-head@freebsd.org, Cy Schubert <Cy.Schubert@cschubert.com> Subject: Re: svn: head/usr.bin: . trim Message-ID: <CAH7qZfs8qTEEosBmnt5TbXAZ%2BX_4Ty1EOHw9MuQTF%2Bmj=0dGuw@mail.gmail.com> In-Reply-To: <201811301646.wAUGkICh019024@pdx.rh.CN85.dnsmgr.net> References: <CANCZdfpEgOrPDbwe%2BnKAYdi6wo-=odpcuUnj4fjYrsUeTC5Xpw@mail.gmail.com> <201811301646.wAUGkICh019024@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Well, I personally think "erase" better describes the option in question. "delete" is ambiguous, since nothing is really "deleted" here and "trim" refers to a name of a particular command in a particular protocol, which may or may not be around in 10 years from now. However, it looks like the industry has settled on that term for now and we've adopted utility with that very name, so I've updated my review request with that. https://reviews.freebsd.org/D18382 Other than that, it would work just as Warner has described. That all being said, I think it might need some other option to actually zero-out block before we trim them out. What I discovered is that unlike say our md(4), actual SATA hard drives may still return some, possibly random, data after BIO_DELETE'ing the corresponding block. So if you have say a big file filled with zeroes for whatever reason, then making a copy of your fs with conv=trim would likely result in some old garbage in that file after such an operation, unless you zero-out the content in advance. As an option, I could possibly make a modifications so that: "conv=sparse,trim" performs just a TRIM "conv=trim" performs write(NIL)+TRIM Then we can have a cake and eat it too. :) -Max On Fri, Nov 30, 2018 at 9:03 AM Rodney W. Grimes < freebsd@pdx.rh.cn85.dnsmgr.net> wrote: > > On Fri, Nov 30, 2018 at 5:57 AM Alexey Dokuchaev <danfe@freebsd.org> > wrote: > > > > > On Fri, Nov 30, 2018 at 07:27:46PM +0700, Eugene Grosbein wrote: > > > > 30.11.2018 18:55, Alexey Dokuchaev wrote: > > > > > > > > >>> Another point: the manpage says, "It is only relevant for flash > based > > > > >>> storage devices that use wear-leveling algorithms", which is an > > > argument > > > > >>> against generic "trim". I would mind less of it would be called > > > ftrim(8) > > > > >>> or ssd_trim(8) or flash_trim(8), but still prefer Maxim's > approach. > > > > > > > > [skip] > > > > > > > > > Yes, I understand you. Like I've said, a little more > > > flash-media-related > > > > > name would perhaps be more appropriate for such an utility. > > > > > > > > This excludes virtio_blk and ZFS. Perhaps, manpage should be > corrected > > > > as quoted phrase has been taken from news -E description as is. > > > > > > How about mtrim(8) or media_trim(8)? I vaguely when back in times > misc/mc > > > was installed as bin/midc because some commercial Unix implementation > had > > > "mc" as a "media copy" command or something like that. > > > > > > > We should just put it in dd and remove this experiment. Both of these > > suggested names are horrible. They are too specific. And the notion that > > trim is too generic may have some merit, but the cure is worse than the > > disease. > > > > So I'm back to my point: we should just put it into dd and move on with > our > > lives. It's really the right place for it. > > > > Why? > > > > Because then we can have 'dd if=image of=/dev/foo conf=sparse,erase' and > it > > conf -> conv, and why erase? We are not actually erasing anything > during this "copy" operation. I am having some confusion as to > how the above would actually do the same thing that trim(8) implements. > > I do not really care if this is implemented as trim(8) or part of > dd, either way is reasonable, though I am upset at repeating the > discussion that already occured pre commit. Seems not enough > committers follow hackers any more, so that has become a poor > forum for vettting ideas, and now we post commit vet them on > -commit. > > > will erase the bits of the drive that are all 0's. We won't have to > resort > > to weird hacks to make most of them trimmed. While this works only on > media > > where trim is persistently 0's, that describes all modern flash media and > > most (all?) of the virtualization / thin storage scenarios I'm aware of. > > You can't do that with the current utility, at least not w/o a lot of > > effort. > > If your reading from file image and writting to dev foo I do > not see that description matching the above command invocation. > > I think it would be: > dd if=/dev/foo of=/dev/foo conv=noerror,sync,trim > sparse is not involved, it is for files, not devices. > erase imho is the wrong keyword, nothing in the trim/delete > world calls this operation erase do they? > trim could imply noerror,sync. > > -- > Rod Grimes > rgrimes@freebsd.org > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAH7qZfs8qTEEosBmnt5TbXAZ%2BX_4Ty1EOHw9MuQTF%2Bmj=0dGuw>