svn: head/usr.bin: . trim

[Warner Losh]

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
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.

Warner