> On Fri, Nov 30, 2018 at 5:57 AM Alexey Dokuchaev <da...@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 rgri...@freebsd.org
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
