svn commit: r343118 - in head/usr.sbin: . trim

Rodney W. Grimes freebsd at pdx.rh.CN85.dnsmgr.net
Fri Jan 18 00:48:54 UTC 2019


> On Thu, Jan 17, 2019 at 3:43 PM Conrad Meyer <cem at freebsd.org> wrote:
> 
> > On Thu, Jan 17, 2019 at 1:16 PM Eugene Grosbein <eugen at freebsd.org> wrote:
> > >
> > > 18.01.2019 3:23, Conrad Meyer ?????:
> > >
> > > > Please back it out; stop attributing code review to "hackers@," which
> > > > can not (it's a list, not individuals) and did not review this
> > > > changeset; and put it on phabricator for actual review.
> > >
> > > There is already https://reviews.freebsd.org/D18380 by imp
> > > and there were over 6 weeks since it had an update.
> > > Newly committed code has most of its changes.
> >
> > Your response does not address *any* of the above concerns.  It's just
> > unrelated.
> >
> 
> Yes.
> 
> 
> > The review you linked to isn't one you submitted for this change; it's
> > Warner's, and that one stalled because you were such a jerk to him
> > last time that he needed time off from you.
> >
> 
> I abandoned it because dd is the better way to go because it can transfer
> images with 0's and TRIM the zero'd pages (and only the zero'd pages). Sure
> dd is hard to use, but it's not that hard to use.

I strongly disagree that dd is the proper place for this tool,
dd is far to easy a way to destroy data when trying to do this
type of operation and should be the last choice for implementing
what is normally a very safe thing to do.

And as eugene points out dd can not easily be made
to do "trim ada0 ada1 ada4"  which is probably the
far more common use of this command.

dd's ability to do sparse(ing) of a file should NOT be
overloaded with a device layer block trimming function.

> 
> 
> > If you want to socialize, revive, or expedite someone else's review,
> > maybe add a new comment to the review, or post a discussion hackers@,
> > or something like that.  You still can't attribute code review to
> > hackers@, especially as no such review happened.
> >
> 
> I think it should be backed out. Especially since it hijacks my work and my
> name to try to ram it into the tree.
> 
> I'm very much not amused.

Nor am I with some of the reactoin to the commit :-(

-- 
Rod Grimes                                                 rgrimes at freebsd.org


More information about the svn-src-head mailing list