svn: head/usr.bin: . trim

[Rodney W. Grimes]

> 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