Re: [PATCH] Support for thresholds in du(1)
On (04/02/2010 23:24), jhell wrote:
>
> On Thu, 4 Feb 2010 06:55, gleb.kurtsou@ wrote:
> > On (25/02/2009 17:24), Mel wrote:
> >> Hi,
> >>
> >> attached is a small patch to add threshold support to du(1). I've been
> >> using
> >> it on 7-STABLE machines for a while, cause I got tired of the noise I get
> >> when sorting and then reformatting to human-readable. Especially since
> >> sorting isn't part of the equasion "I'd like to see all dirs exceeding a
> >> given size".
> >> I've not updated the manpage on -STABLE yet, should be the same as HEAD.
> >>
> >> Example usage:
> >> # du -xht 20m .
> >> 29M./contrib/binutils
> >> 52M./contrib/gcc
> >> 237M./contrib
> >> 35M./crypto
> >> 28M./lib
> >> 20M./share
> >> 55M./sys/dev
> >> 139M./sys
> >> 545M.
> >>
> >> I'll file a PR for it, if there's no objections to this feature /
> >> implementation, the style(9) or the usage of -t.
> >> --
> >> Mel
> >
> > Hi,
> >
> > I've cleaned up original patch:
> > * fixed style and some bugs
> > * as suggested changed it to use expand_number
> > * implemented support for negative threshold values
> >
> > I find the patch very useful. Does it look ok to be commited, or should
> > I file a PR so it won't get lost once again.
> >
> > Example usage:
> > src/sys/crypto % du -ht 100k
> > 137K./des
> > 482K.
> > src/sys/crypto % du -A -ht +100k
> > 129K./des
> > 446K.
> > src/sys/crypto % du -ht -100k
> > 56K./camellia
> > 11K./salsa20
> > 38K./sha2
> > 9.0K./rc4
> > 68K./des/arch/i386
> > 70K./des/arch
> > 88K./rijndael
> > 37K./via
> > 8.0K./hmac
> > 36K./blowfish/arch/i386
> > 37K./blowfish/arch
> > 85K./blowfish
> >
>
>
> Also not to be picky but I can see this being raised in another email at a
> later time.
>
> For Each
> du -ht +1.5{M,G,T,P}
>
> Would be something nice to compliment this so you do not have to revert
> back to say "1440k" when wanting to say 1.5m and so on for larger sizes.
>
> Also I think to be fully supportive it should have the capability to do at
> the least -N bits & +-N bytes.
Let's keep it simple, these features are are not hard to implement, but
overcomplicate such simple utility as du(1). If one needs more
sophisticated disk usage reporting he's likely to have 3rd party utils
installed already.
> Thanks for the work that you have done on this.
>
> --
>
> jhell
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] Support for thresholds in du(1)
On Thu, 4 Feb 2010 23:51, jasonspiro4@ wrote: On Thu, Feb 4, 2010 at 9:30 PM, jhell wrote: I like it!. It looks like a really useful option. Though if you really need to free up a lot of space, try a Freshmeat search[1] for [ disk usage ]. It reveals many tools that look even better, including ncdu[2] which doesn't require Xorg. But I doubt that any of them ship with FreeBSD by default. I think the du manpage[3]'s "SEE ALSO" section should be revised to include ncdu(1), xdiskusage(1), baobab(1), and kdirstat(1). (Baobab requires Gnome, and KDirStat requires KDE.) What do you think? To me it is a annoyance when I see a man page reference something that is not already installed on the system especially if it does not reference a URL. Back end utilities should really only list their friends in see also and not friends of friends and their friends. ;) My favorite that can run on anything that can run java jre/jdk is sysutils/jdiskreport. Although certain WM's do not work well with java this is a very portable utility. This certainly reduces some piping but as long as it is not integrated upstream it will only become more of a responsibility on FreeBSD's behalf to maintain it. If someone has the original authors email address I would say lets include him on this and see what he thinks. This would probably be the same for the pkill thread that I am involved in to. CC'ing responsible party for that thread. What do you mean? Do you mean that maintaining half a dozen lines of extra code added to pkill(1) would be a burden for the FreeBSD team? :) Yeah. I am more of a lean practitioner so I try to always look for the best way or if you will the least hands on way of managing things. In this case the less code that has to be merged upon update the better and more time that is available to developers to work on much needed other tasks. Five minutes not opening a editor and merging code could better be used getting a cup of coffee to stay awake while hacking on ZFS or utmpx rather than pkill or du. ;) ^ [1]. http://freshmeat.net/search/?q=disk+usage ^ [2]. http://freshmeat.net/projects/ncdu ^ [3]. http://www.freebsd.org/cgi/man.cgi?query=du&manpath=FreeBSD+9.0-CURRENT -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] Support for thresholds in du(1)
On Thu, Feb 4, 2010 at 8:51 PM, Jason A. Spiro wrote: > On Thu, Feb 4, 2010 at 9:30 PM, jhell wrote: > >> I like it!. > > It looks like a really useful option. Though if you really need to > free up a lot of space, try a Freshmeat search[1] for [ disk usage ]. > It reveals many tools that look even better, including ncdu[2] which > doesn't require Xorg. But I doubt that any of them ship with FreeBSD > by default. > > I think the du manpage[3]'s "SEE ALSO" section should be revised to > include ncdu(1), xdiskusage(1), baobab(1), and kdirstat(1). (Baobab > requires Gnome, and KDirStat requires KDE.) What do you think? > >> This certainly reduces some piping but as long as it is not >> integrated upstream it will only become more of a responsibility on >> FreeBSD's behalf to maintain it. If someone has the original authors email >> address I would say lets include him on this and see what he thinks. >> >> This would probably be the same for the pkill thread that I am involved in >> to. CC'ing responsible party for that thread. > > What do you mean? Do you mean that maintaining half a dozen lines of > extra code added to pkill(1) would be a burden for the FreeBSD team? > :) Shouldn't, but as I've learned before a few times -- it only takes one line of code to fubar a one man-rockfight (or screw up a system :)...)... Cheers, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] Support for thresholds in du(1)
On Thu, Feb 4, 2010 at 9:30 PM, jhell wrote: > I like it!. It looks like a really useful option. Though if you really need to free up a lot of space, try a Freshmeat search[1] for [ disk usage ]. It reveals many tools that look even better, including ncdu[2] which doesn't require Xorg. But I doubt that any of them ship with FreeBSD by default. I think the du manpage[3]'s "SEE ALSO" section should be revised to include ncdu(1), xdiskusage(1), baobab(1), and kdirstat(1). (Baobab requires Gnome, and KDirStat requires KDE.) What do you think? > This certainly reduces some piping but as long as it is not > integrated upstream it will only become more of a responsibility on > FreeBSD's behalf to maintain it. If someone has the original authors email > address I would say lets include him on this and see what he thinks. > > This would probably be the same for the pkill thread that I am involved in > to. CC'ing responsible party for that thread. What do you mean? Do you mean that maintaining half a dozen lines of extra code added to pkill(1) would be a burden for the FreeBSD team? :) ^ [1]. http://freshmeat.net/search/?q=disk+usage ^ [2]. http://freshmeat.net/projects/ncdu ^ [3]. http://www.freebsd.org/cgi/man.cgi?query=du&manpath=FreeBSD+9.0-CURRENT ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] Support for thresholds in du(1)
On Thu, 4 Feb 2010 06:55, gleb.kurtsou@ wrote:
On (25/02/2009 17:24), Mel wrote:
Hi,
attached is a small patch to add threshold support to du(1). I've been using
it on 7-STABLE machines for a while, cause I got tired of the noise I get
when sorting and then reformatting to human-readable. Especially since
sorting isn't part of the equasion "I'd like to see all dirs exceeding a
given size".
I've not updated the manpage on -STABLE yet, should be the same as HEAD.
Example usage:
# du -xht 20m .
29M./contrib/binutils
52M./contrib/gcc
237M./contrib
35M./crypto
28M./lib
20M./share
55M./sys/dev
139M./sys
545M.
I'll file a PR for it, if there's no objections to this feature /
implementation, the style(9) or the usage of -t.
--
Mel
Hi,
I've cleaned up original patch:
* fixed style and some bugs
* as suggested changed it to use expand_number
* implemented support for negative threshold values
I find the patch very useful. Does it look ok to be commited, or should
I file a PR so it won't get lost once again.
Example usage:
src/sys/crypto % du -ht 100k
137K./des
482K.
src/sys/crypto % du -A -ht +100k
129K./des
446K.
src/sys/crypto % du -ht -100k
56K./camellia
11K./salsa20
38K./sha2
9.0K./rc4
68K./des/arch/i386
70K./des/arch
88K./rijndael
37K./via
8.0K./hmac
36K./blowfish/arch/i386
37K./blowfish/arch
85K./blowfish
Also not to be picky but I can see this being raised in another email at a
later time.
For Each
du -ht +1.5{M,G,T,P}
Would be something nice to compliment this so you do not have to revert
back to say "1440k" when wanting to say 1.5m and so on for larger sizes.
Also I think to be fully supportive it should have the capability to do at
the least -N bits & +-N bytes.
Thanks for the work that you have done on this.
--
jhell
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] Support for thresholds in du(1)
On Thu, 4 Feb 2010 06:55, gleb.kurtsou@ wrote: On (25/02/2009 17:24), Mel wrote: Hi, attached is a small patch to add threshold support to du(1). I've been using it on 7-STABLE machines for a while, cause I got tired of the noise I get when sorting and then reformatting to human-readable. Especially since sorting isn't part of the equasion "I'd like to see all dirs exceeding a given size". I've not updated the manpage on -STABLE yet, should be the same as HEAD. Example usage: # du -xht 20m . 29M./contrib/binutils 52M./contrib/gcc 237M./contrib 35M./crypto 28M./lib 20M./share 55M./sys/dev 139M./sys 545M. I'll file a PR for it, if there's no objections to this feature / implementation, the style(9) or the usage of -t. -- Mel Hi, I've cleaned up original patch: * fixed style and some bugs * as suggested changed it to use expand_number * implemented support for negative threshold values I find the patch very useful. Does it look ok to be commited, or should I file a PR so it won't get lost once again. Example usage: src/sys/crypto % du -ht 100k 137K./des 482K. src/sys/crypto % du -A -ht +100k 129K./des 446K. src/sys/crypto % du -ht -100k 56K./camellia 11K./salsa20 38K./sha2 9.0K./rc4 68K./des/arch/i386 70K./des/arch 88K./rijndael 37K./via 8.0K./hmac 36K./blowfish/arch/i386 37K./blowfish/arch 85K./blowfish I would recommend generating this patch as a unified diff or a svn or cvs diff whichever version you checked out your tree with. -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] Support for thresholds in du(1)
On Thu, 4 Feb 2010 06:55, gleb.kurtsou@ wrote: On (25/02/2009 17:24), Mel wrote: Hi, attached is a small patch to add threshold support to du(1). I've been using it on 7-STABLE machines for a while, cause I got tired of the noise I get when sorting and then reformatting to human-readable. Especially since sorting isn't part of the equasion "I'd like to see all dirs exceeding a given size". I've not updated the manpage on -STABLE yet, should be the same as HEAD. Example usage: # du -xht 20m . 29M./contrib/binutils 52M./contrib/gcc 237M./contrib 35M./crypto 28M./lib 20M./share 55M./sys/dev 139M./sys 545M. I'll file a PR for it, if there's no objections to this feature / implementation, the style(9) or the usage of -t. -- Mel Hi, I've cleaned up original patch: * fixed style and some bugs * as suggested changed it to use expand_number * implemented support for negative threshold values I find the patch very useful. Does it look ok to be commited, or should I file a PR so it won't get lost once again. Example usage: src/sys/crypto % du -ht 100k 137K./des 482K. src/sys/crypto % du -A -ht +100k 129K./des 446K. src/sys/crypto % du -ht -100k 56K./camellia 11K./salsa20 38K./sha2 9.0K./rc4 68K./des/arch/i386 70K./des/arch 88K./rijndael 37K./via 8.0K./hmac 36K./blowfish/arch/i386 37K./blowfish/arch 85K./blowfish I like it!. This certainly reduces some piping but as long as it is not integrated upstream it will only become more of a responsibility on FreeBSD's behalf to maintain it. If someone has the original authors email address I would say lets include him on this and see what he thinks. This would probably be the same for the pkill thread that I am involved in to. CC'ing responsible party for that thread. Best regards. This message was supposed to arrive 9 hours ago but there was some ISP problems that prevented me from sending it. -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] Support for thresholds in du(1)
On (25/02/2009 17:24), Mel wrote:
> Hi,
>
> attached is a small patch to add threshold support to du(1). I've been using
> it on 7-STABLE machines for a while, cause I got tired of the noise I get
> when sorting and then reformatting to human-readable. Especially since
> sorting isn't part of the equasion "I'd like to see all dirs exceeding a
> given size".
> I've not updated the manpage on -STABLE yet, should be the same as HEAD.
>
> Example usage:
> # du -xht 20m .
> 29M./contrib/binutils
> 52M./contrib/gcc
> 237M./contrib
> 35M./crypto
> 28M./lib
> 20M./share
> 55M./sys/dev
> 139M./sys
> 545M.
>
> I'll file a PR for it, if there's no objections to this feature /
> implementation, the style(9) or the usage of -t.
> --
> Mel
Hi,
I've cleaned up original patch:
* fixed style and some bugs
* as suggested changed it to use expand_number
* implemented support for negative threshold values
I find the patch very useful. Does it look ok to be commited, or should
I file a PR so it won't get lost once again.
Example usage:
src/sys/crypto % du -ht 100k
137K./des
482K.
src/sys/crypto % du -A -ht +100k
129K./des
446K.
src/sys/crypto % du -ht -100k
56K./camellia
11K./salsa20
38K./sha2
9.0K./rc4
68K./des/arch/i386
70K./des/arch
88K./rijndael
37K./via
8.0K./hmac
36K./blowfish/arch/i386
37K./blowfish/arch
85K./blowfish
diff --git a/usr.bin/du/du.1 b/usr.bin/du/du.1
index af2ff84..b0e1748 100644
--- a/usr.bin/du/du.1
+++ b/usr.bin/du/du.1
@@ -42,7 +42,7 @@
.Nm
.Op Fl A
.Op Fl H | L | P
-.Op Fl a | s | d Ar depth
+.Op Fl a | s | d Ar depth | t Ar threshold
.Op Fl c
.Op Fl l
.Op Fl h | k | m | B Ar blocksize
@@ -107,6 +107,14 @@ This option exists solely for conformance with
Display an entry for each specified file.
(Equivalent to
.Fl d Li 0 )
+.It Fl t Ar threshold
+Display only entries for which size exceeds
+.Ar threshold .
+If
+.Ar threshold
+is negative, display only entries for which size is less then absolute
+value of
+.Ar threshold .
.It Fl d Ar depth
Display an entry for all files and directories
.Ar depth
diff --git a/usr.bin/du/du.c b/usr.bin/du/du.c
index 63677f5..ff62c5b 100644
--- a/usr.bin/du/du.c
+++ b/usr.bin/du/du.c
@@ -90,6 +90,7 @@ main(int argc, char *argv[])
FTS *fts;
FTSENT *p;
off_t savednumber, curblocks;
+ int64_t threshold, threshold_sign;
int ftsoptions;
int listall;
int depth;
@@ -106,12 +107,14 @@ main(int argc, char *argv[])
save = argv;
ftsoptions = 0;
savednumber = 0;
+ threshold = 0;
+ threshold_sign = 1;
cblocksize = DEV_BSIZE;
blocksize = 0;
depth = INT_MAX;
SLIST_INIT(&ignores);
- while ((ch = getopt(argc, argv, "AB:HI:LPasd:chklmnrx")) != -1)
+ while ((ch = getopt(argc, argv, "AB:HI:LPasd:chklmnrt:x")) != -1)
switch (ch) {
case 'A':
Aflag = 1;
@@ -179,6 +182,14 @@ main(int argc, char *argv[])
break;
case 'r':/* Compatibility. */
break;
+ case 't' :
+ if (expand_number(optarg, &threshold) != 0 ||
+ threshold == 0) {
+ warnx("invalid threshold: %s", optarg);
+ usage();
+ } else if (threshold < 0)
+ threshold_sign = -1;
+ break;
case 'x':
ftsoptions |= FTS_XDEV;
break;
@@ -248,6 +259,10 @@ main(int argc, char *argv[])
blocksize /= DEV_BSIZE;
}
+ if (threshold != 0)
+ threshold = howmany(threshold / DEV_BSIZE * cblocksize,
+ blocksize);
+
rval = 0;
(void)signal(SIGINFO, siginfo);
@@ -271,7 +286,9 @@ main(int argc, char *argv[])
p->fts_parent->fts_bignum += p->fts_bignum +=
curblocks;
- if (p->fts_level <= depth) {
+ if (p->fts_level <= depth && threshold <=
+ threshold_sign * howmany(p->fts_bignum *
+ cblocksize, blocksize)) {
if (hflag) {
prthumanval(p->fts_bignum);
(void)printf("\t%s\n", p->fts_path);
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] Support for thresholds in du(1)
Ed Schouten wrote: > * Mel wrote: >> Example usage: >> # du -xht 20m . >> 29M./contrib/binutils >> 52M./contrib/gcc >> 237M./contrib >> 35M./crypto >> 28M./lib >> 20M./share >> 55M./sys/dev >> 139M./sys >> 545M. > > Ooh! That looks awesome! > Would this option benefit from perhaps swinging both ways? As in: du -t +20m (show >20mb) du -t -20m (show <20mb) Or something along those lines ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] Support for thresholds in du(1)
* Mel wrote: > Example usage: > # du -xht 20m . > 29M./contrib/binutils > 52M./contrib/gcc > 237M./contrib > 35M./crypto > 28M./lib > 20M./share > 55M./sys/dev > 139M./sys > 545M. Ooh! That looks awesome! -- Ed Schouten WWW: http://80386.nl/ pgph7lwd43C6C.pgp Description: PGP signature
Re: [PATCH] Support for thresholds in du(1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mel wrote: > On Wednesday 25 February 2009 18:36:45 Xin LI wrote: >> Mel wrote: >> [...] >> >>> I'll file a PR for it, if there's no objections to this feature / >>> implementation, the style(9) or the usage of -t. >> One comment: you may want to consider using expand_number(3) instead of >> rolling your own version > > Cool thanks, didn't know about that one and was actually considering a > request > for this API. Maybe strtonum/atoi/stroll and friends should .Xr this API? Maybe, perhaps also humanize_numbers... We may also want NetBSD's dehumanize_number as well... - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkmmGZUACgkQi+vbBBjt66DX0ACfSge9+MA5P98MOYf4LfF+rKn8 Nq8AoLCko53l4YKQrZUQW1PJp9oUVAw4 =6ok+ -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] Support for thresholds in du(1)
On Wednesday 25 February 2009 18:36:45 Xin LI wrote: > Mel wrote: > [...] > > > I'll file a PR for it, if there's no objections to this feature / > > implementation, the style(9) or the usage of -t. > > One comment: you may want to consider using expand_number(3) instead of > rolling your own version Cool thanks, didn't know about that one and was actually considering a request for this API. Maybe strtonum/atoi/stroll and friends should .Xr this API? -- Mel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] Support for thresholds in du(1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mel wrote: [...] > I'll file a PR for it, if there's no objections to this feature / > implementation, the style(9) or the usage of -t. One comment: you may want to consider using expand_number(3) instead of rolling your own version Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkmmDk0ACgkQi+vbBBjt66A1pgCghpIS/bOgflo0JKNBlKZlBzDf H0IAn21ZJNk1fT6YWDzO0e6nK4dUmJd0 =FFjB -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
