svn: head/usr.bin: . trim

[Maxim Sobolev]

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 at pdx.rh.cn85.dnsmgr.net> wrote:

> > On Fri, Nov 30, 2018 at 5:57 AM Alexey Dokuchaev <danfe at 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 at freebsd.org
>
>