Date: Fri, 23 Nov 2018 08:00:58 -0800 (PST) From: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> To: lev@freebsd.org Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Freebsd hackers list <freebsd-hackers@freebsd.org>, Eugene Grosbein <eugen@grosbein.net> Subject: Re: TRIM utility Message-ID: <201811231600.wANG0wHc083199@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <ca200443-f997-4d84-cbd5-592243714898@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 23.11.2018 14:19, Poul-Henning Kamp wrote: > > >>> Currently it has four options, all of them are, hmm, optional: > > Isn't this the kind of thing that dd(1) should learn about instead ? > One utility to done one thing very well? :-) > > dd(1) is way overloaded, IMHO. I agree here, we do too much of trying to shoe horn things into existing utilities then we end up with a command parser that only a mother could love. trim, hdtrim, blktrim, camtrim, any of them are fine, fstrim is bad, this is not a filesystem op, too bad the next thing that comes along that is "trim" like well have to pick something other than trim. I might ask would it be horribly hard to access the "secure erase" feature from this utility? Or do we have another that can easily get at that function, that is usually the prefered vendor specific method to "trim" the complete drive, often restoring badly leveled SSD's to a performant and usable state. -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201811231600.wANG0wHc083199>