01.12.2018 8:54, Steven Hartland wrote:
> What I was referring to is ZFS performs a delete of blocks when it
> initializes a volume, so there's usually no need to perform a manual step
> there.
It may be needed after ZIL or ZFS Cache partition became unneeded.
On 30/11/2018 22:09, Eugene Grosbein wrote:
01.12.2018 4:29, Steven Hartland wrote:
On 30/11/2018 21:16, Eugene Grosbein wrote:
30.11.2018 21:23, Warner Losh wrote:
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
01.12.2018 4:29, Steven Hartland wrote:
> On 30/11/2018 21:16, Eugene Grosbein wrote:
>> 30.11.2018 21:23, Warner Losh wrote:
>>
>>> 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 can't we have two
ZFS already does that no need for a separate tool
On 30/11/2018 21:16, Eugene Grosbein wrote:
30.11.2018 21:23, Warner Losh wrote:
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 can't we have two implementations?
30.11.2018 21:23, Warner Losh wrote:
> 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 can't we have two implementations? Diversity is good thing.
I can imagine erasing a partition with ZFS Cache or ZIL inside and
Well, I personally think "erase" better describes the option in question.
"delete" is ambiguous, since nothing is really "deleted" here and "trim"
refers to a name of a particular command in a particular protocol, which
may or may not be around in 10 years from now. However, it looks like the
> On Fri, Nov 30, 2018 at 5:57 AM Alexey Dokuchaev 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
On Fri, Nov 30, 2018 at 4:45 AM Eugene Grosbein wrote:
> 30.11.2018 18:34, 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
On Fri, Nov 30, 2018 at 5:57 AM Alexey Dokuchaev 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
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".
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
On Fri, Nov 30, 2018 at 06:44:48PM +0700, Eugene Grosbein wrote:
> 30.11.2018 18:34, 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
30.11.2018 18:34, 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
On Fri, Nov 30, 2018 at 06:12:12PM +0700, Eugene Grosbein wrote:
> 30.11.2018 17:57, Alexey Dokuchaev wrote:
> > On Fri, Nov 30, 2018 at 09:49:55AM +0100, Baptiste Daroussin wrote:
> >> On Fri, Nov 30, 2018 at 08:31:17AM +, Steven Hartland wrote:
> >>> Personally I disagree, chances of people
30.11.2018 17:57, Alexey Dokuchaev wrote:
> On Fri, Nov 30, 2018 at 09:49:55AM +0100, Baptiste Daroussin wrote:
>> On Fri, Nov 30, 2018 at 08:31:17AM +, Steven Hartland wrote:
>>> Personally I disagree, chances of people finding that option in dd
>>> is slim, a dedicated trim utility makes
On Fri, Nov 30, 2018 at 09:49:55AM +0100, Baptiste Daroussin wrote:
> On Fri, Nov 30, 2018 at 08:31:17AM +, Steven Hartland wrote:
> > Personally I disagree, chances of people finding that option in dd
> > is slim, a dedicated trim utility makes much more sense to me. Sure
> > have both that's
On Fri, Nov 30, 2018 at 08:31:17AM +, Steven Hartland wrote:
> Personally I disagree, chances of people finding that option in dd is slim,
> a dedicated trim utility makes much more sense to me. Sure have both that's
> cool but keep the trim would be my vote.
I also like the idea of a simple
: eu...@freebsd.org; svn-src-h...@freebsd.org;
svn-src-all@freebsd.org; src-committers
Subject: Re: svn: head/usr.bin: . trim
On Thu, Nov 29, 2018 at 10:36:02AM -0800, Maxim Sobolev wrote:
> Interesting. I have a similar functionality implemented as an option for
> the dd utility in my pi
For those interested, dd(1) patch is here:
https://reviews.freebsd.org/D18382
Feedback is much appreciated. Thanks!
-Max
On Thu, Nov 29, 2018 at 5:01 PM Alexey Dokuchaev wrote:
> On Thu, Nov 29, 2018 at 10:36:02AM -0800, Maxim Sobolev wrote:
> > Interesting. I have a similar functionality
To: Maxim Sobolev
Cc: eu...@freebsd.org; svn-src-h...@freebsd.org; svn-src-all@freebsd.org;
src-committers
Subject: Re: svn: head/usr.bin: . trim
On Thu, Nov 29, 2018 at 10:36:02AM -0800, Maxim Sobolev wrote:
> Interesting. I have a similar functionality implemented as an option for
> the dd u
On Thu, Nov 29, 2018 at 10:36:02AM -0800, Maxim Sobolev wrote:
> Interesting. I have a similar functionality implemented as an option for
> the dd utility in my pipeline (conv=erase).
Which probably makes a better place rather than adding 4-letter program,
commonly named ("trim" is a simple
Interesting. I have a similar functionality implemented as an option for
the dd utility in my pipeline (conv=erase).
-Max
On Thu, Nov 29, 2018 at 6:21 AM Eugene Grosbein wrote:
> Author: eugen
> Date: Thu Nov 29 14:21:26 2018
> New Revision: 341232
> URL:
22 matches
Mail list logo
