Re: svn: head/usr.bin: . trim
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. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn: head/usr.bin: . trim
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 can't we have two implementations? Diversity is good thing. I can imagine erasing a partition with ZFS Cache or ZIL inside and "trim /dev/da0p2 /dev/da0p3" looks much better :-) ZFS already does that no need for a separate tool Think of media taken out of (possibly already dead) ZFS-based to UFS-only system. By the way, how exactly do you trim previously ZIL partition withing working ZFS-based system? You could use camcontrol which can perform a secure erase on the device, but that's obviously device wide not a specific partition. 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. For reference this behavior can be disabled by setting vfs.zfs.vdev.trim_on_init=0 Regards Steve ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn: head/usr.bin: . trim
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 implementations? Diversity is good thing. >> >> I can imagine erasing a partition with ZFS Cache or ZIL inside and >> "trim /dev/da0p2 /dev/da0p3" looks much better :-) > > ZFS already does that no need for a separate tool Think of media taken out of (possibly already dead) ZFS-based to UFS-only system. By the way, how exactly do you trim previously ZIL partition withing working ZFS-based system? ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn: head/usr.bin: . trim
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? Diversity is good thing. I can imagine erasing a partition with ZFS Cache or ZIL inside and "trim /dev/da0p2 /dev/da0p3" looks much better :-) ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn: head/usr.bin: . trim
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 "trim /dev/da0p2 /dev/da0p3" looks much better :-) ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn: head/usr.bin: . trim
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 industry has settled on that term for now and we've adopted utility with that very name, so I've updated my review request with that. https://reviews.freebsd.org/D18382 Other than that, it would work just as Warner has described. That all being said, I think it might need some other option to actually zero-out block before we trim them out. What I discovered is that unlike say our md(4), actual SATA hard drives may still return some, possibly random, data after BIO_DELETE'ing the corresponding block. So if you have say a big file filled with zeroes for whatever reason, then making a copy of your fs with conv=trim would likely result in some old garbage in that file after such an operation, unless you zero-out the content in advance. As an option, I could possibly make a modifications so that: "conv=sparse,trim" performs just a TRIM "conv=trim" performs write(NIL)+TRIM Then we can have a cake and eat it too. :) -Max On Fri, Nov 30, 2018 at 9:03 AM Rodney W. Grimes < free...@pdx.rh.cn85.dnsmgr.net> wrote: > > 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 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-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn: head/usr.bin: . trim
> 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 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-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn: head/usr.bin: . trim
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 less of it would be called ftrim(8) > > or ssd_trim(8) or flash_trim(8), but still prefer Maxim's approach. > > Speaking of naming issues: > > NAME > dd - convert and copy a file > > I still prefer unix-way: "each utility does one simple task". > And that's not about dd :-( > That ship has sailed on dd. Even v7 dd wasn't good at doing one simple task... Warner ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn: head/usr.bin: . trim
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 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 ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn: head/usr.bin: . trim
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. ./danfe ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn: head/usr.bin: . 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 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. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn: head/usr.bin: . trim
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 would mind less of it would be called ftrim(8) > > or ssd_trim(8) or flash_trim(8), but still prefer Maxim's approach. > > Speaking of naming issues: > > NAME > dd - convert and copy a file IMHO this description should be fixed (but that's the whole another bug). > I still prefer unix-way: "each utility does one simple task". > And that's not about dd :-( Yes, I understand you. Like I've said, a little more flash-media-related name would perhaps be more appropriate for such an utility. ./danfe ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn: head/usr.bin: . trim
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 flash_trim(8), but still prefer Maxim's approach. Speaking of naming issues: NAME dd - convert and copy a file I still prefer unix-way: "each utility does one simple task". And that's not about dd :-( ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn: head/usr.bin: . trim
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 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.
> >
> > Having both is OK when there's no code duplication involved (e.g. like
> > hd(1) being a handy hardlink to hexdump(1)), yet again...
> >
> >> I also like the idea of a simple dedicated tool with an obvious name.
> >
> > ... "Obvious" names can cut both ways. They can be too generic and thus
> > create a clash in the future. They can be ambiguous ("trim" can just as
> > easily be a tool that excessive whitespace from text files).
>
> In theory, it can. In practice, it did not for 25 years of FreeBSD
> existence despite of whitespace processing being much more generic task.
>
> Maybe that's because we already have "fmt -s" since 3BSD to do that? :-)
Actually, while perhaps whitespace trimming was not the best example (no
surprise given it was my first idea of "trimming" other than trimming a
beard), your reply is quite helpful: text formatter tasks of different
kinds are grouped under one fmt(1) tool. Likewise, dd(1) is what people
normally use when talking to storage media.
How often does average Joe user need to explicitly trim their flash
disks to warrant a dedicated "trim" utility in the base? Shouldn't it
just happen automagically most of the times, and require some manual
intervention under some specific circumstances?
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.
./danfe
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn: head/usr.bin: . trim
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 much more sense to me. Sure
>>> have both that's cool but keep the trim would be my vote.
>
> Having both is OK when there's no code duplication involved (e.g. like
> hd(1) being a handy hardlink to hexdump(1)), yet again...
>
>> I also like the idea of a simple dedicated tool with an obvious name.
>
> ... "Obvious" names can cut both ways. They can be too generic and thus
> create a clash in the future. They can be ambiguous ("trim" can just as
> easily be a tool that excessive whitespace from text files).
In theory, it can. In practice, it did not for 25 years of FreeBSD existence
despite of whitespace processing being much more generic task.
Maybe that's because we already have "fmt -s" since 3BSD to do that? :-)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn: head/usr.bin: . trim
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 cool but keep the trim would be my vote.
Having both is OK when there's no code duplication involved (e.g. like
hd(1) being a handy hardlink to hexdump(1)), yet again...
> I also like the idea of a simple dedicated tool with an obvious name.
... "Obvious" names can cut both ways. They can be too generic and thus
create a clash in the future. They can be ambiguous ("trim" can just as
easily be a tool that excessive whitespace from text files).
./danfe
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn: head/usr.bin: . trim
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 dedicated tool with an obvious name Bapt signature.asc Description: PGP signature
Re: svn: head/usr.bin: . trim
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.
On 30/11/2018 01:17, Cy Schubert wrote:
Agreed.
---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.
Cy Schubert
or
The need of the many outweighs the greed of the few.
---
From: Alexey Dokuchaev
Sent: 29/11/2018 17:01
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 utility in my pipeline (conv=erase).
Which probably makes a better place rather than adding 4-letter program,
commonly named ("trim" is a simple word), into global namespace. :-/
./danfe
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn: head/usr.bin: . trim
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 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 word), into global namespace. :-/
>
> ./danfe
>
>
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
RE: svn: head/usr.bin: . trim
Agreed.
---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.
Cy Schubert
or
The need of the many outweighs the greed of the few.
---
-Original Message-
From: Alexey Dokuchaev
Sent: 29/11/2018 17:01
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 utility in my pipeline (conv=erase).
Which probably makes a better place rather than adding 4-letter program,
commonly named ("trim" is a simple word), into global namespace. :-/
./danfe
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
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 pipeline (conv=erase).
Which probably makes a better place rather than adding 4-letter program,
commonly named ("trim" is a simple word), into global namespace. :-/
./danfe
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn: head/usr.bin: . trim
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: https://svnweb.freebsd.org/changeset/base/341232 > > Log: > Add new small tool trim(1) to delete contents for blocks on flash > based storage devices that use wear-leveling algorithms. > > Reviewed by: hackers@ > MFC after:1 month > > Added: > head/usr.bin/trim/ > head/usr.bin/trim/Makefile (contents, props changed) > head/usr.bin/trim/trim.1 (contents, props changed) > head/usr.bin/trim/trim.c (contents, props changed) > Modified: > head/usr.bin/Makefile > > Modified: head/usr.bin/Makefile > > == > --- head/usr.bin/Makefile Thu Nov 29 14:21:01 2018(r341231) > +++ head/usr.bin/Makefile Thu Nov 29 14:21:26 2018(r341232) > @@ -159,6 +159,7 @@ SUBDIR= alias \ > touch \ > tput \ > tr \ > + trim \ > true \ > truncate \ > tset \ > > Added: head/usr.bin/trim/Makefile > > == > --- /dev/null 00:00:00 1970 (empty, because file is newly added) > +++ head/usr.bin/trim/Makefile Thu Nov 29 14:21:26 2018(r341232) > @@ -0,0 +1,6 @@ > +# $FreeBSD$ > + > +PROG= trim > +LIBADD=util > + > +.include > > Added: head/usr.bin/trim/trim.1 > > == > --- /dev/null 00:00:00 1970 (empty, because file is newly added) > +++ head/usr.bin/trim/trim.1Thu Nov 29 14:21:26 2018(r341232) > @@ -0,0 +1,166 @@ > +.\" > +.\" Copyright (c) 2018 Eugene Grosbein . > +.\" All rights reserved. > +.\" > +.\" Redistribution and use in source and binary forms, with or without > +.\" modification, are permitted provided that the following conditions > +.\" are met: > +.\" 1. Redistributions of source code must retain the above copyright > +.\"notice, this list of conditions and the following disclaimer. > +.\" 2. Redistributions in binary form must reproduce the above copyright > +.\"notice, this list of conditions and the following disclaimer in the > +.\"documentation and/or other materials provided with the > distribution. > +.\" > +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND > +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE > +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE > LIABLE > +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > CONSEQUENTIAL > +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE > GOODS > +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) > +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, > STRICT > +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY > WAY > +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF > +.\" SUCH DAMAGE. > +.\" > +.\" $FreeBSD$ > +.\" > +.Dd November 29, 2018 > +.Dt TRIM 1 > +.Os > +.Sh NAME > +.Nm trim > +.Nd erase device blocks that have no needed contents > +.Sh SYNOPSIS > +.Nm > +.Op Fl Nfqv > +.Fl [ [lo] Xo > +.Bk -words > +.Sm off > +.Ar offset > +.Op Cm K | k | M | m | G | g | T | t ] > +.Sm on > +.Xc > +.Ek > +.Bk -words > +.Op Fl r Ar rfile > +.Ek > +.Ar device ... > +.Sh DESCRIPTION > +The > +.Nm > +utility erases specified region of the device. > +It is only relevant for flash based storage devices that use wear-leveling > +algorithms. > +.Sy All erased data is lost. > +.Pp > +The following options are available: > +.Bl -tag -width indent > +.It Fl N > +Do not actually erase anything but show what it would do (dry run). > +Implies > +.Fl v . > +This is the default. Overrides > +.Fl f . > +.It Fl f > +Perform the operation. Overrides > +.Fl N . > +.It Fl l Xo > +.Sm off > +.Ar offset > +.Op Cm K | k | M | m | G | g | T | t > +.Sm on > +.Xc > +.It Fl o Xo > +.Sm off > +.Ar offset > +.Op Cm K | k | M | m | G | g | T | t > +.Sm on > +.Xc > +Specify the length > +.Fl l > +of the region to trim or its offset > +.Fl o > +from the beginning of the device. > +.Sy The whole device is erased by default > +unless one or both of these options are presented. > +.Pp > +The argument may be suffixed with one of > +.Cm K , > +.Cm M , > +.Cm G > +or > +.Cm T > +(either upper or lower case) to indicate a multiple of > +Kilobytes, Megabytes, Gigabytes or Terabytes > +respectively. > +.It Fl q > +Do not output anything except of possible error messages (quiet mode). > +Overrides > +.Fl v . > +.It Fl r Ar rfile > +Uses the length of given > +.Ar rfile > +as length of the region to erase.
