Disk Top Ten (dtt) release announcements and discussion
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Disk Top Ten (dtt) release announcements and discussion
dtt is a better "where's my disk space" utility. It quickly summarizes filesystem usage into a "top ten" list of largest subtrees or individual objects. Its output has the unique property that it shows the ten largest single subtrees found at any depth without reporting redundant results. In other words, all the really big chunks float to the top. Sample output:
Subscribe this thread for release announcements such as the one below, and for feature requests and general discussion about the tool.
New in 2.1 alpha (release candidate):
added --inodes option
made option parsing errors fatal (thank you 0XBF)
added support for Perl 5.38.2
made lots of clarifying edits to the manuals
Release 2.1 alpha source package, Slackware 15.0 slackbuild, manuals, and changelog are here: https://metaed.com/papers/dtt/. (If you cannot reach the site, you are connecting from a country that is geoblocked because of high attack rate. At the moment that's CN, VN, RU, HK, SG, IN, KR, TW, BR, JP, and ID. Let me know which country and and I will lower shields for you.)
Hello metaed , Seems kid of odd that using a set -B size , Would report file sizes of '0' .
I can understand why , It just seems odd that the report would not represent them with 0.4 or 0.5 .
Hth , JimL
ie:
Could you please stop opening new threads every time you make a code change? It's just silly.
You can dedicate a single topic to that software of yours and then keep updating the first post with new information.
Seems kid of odd that using a set -B size , Would report file sizes of '0' .
I can understand why , It just seems odd that the report would not represent them with 0.4 or 0.5 .
Hth , JimL
Thank you for being interested enough to ask the question. The answer is that I deliberately pattern dtt's behavior after df and du, except where I feel strongly that the legacy behavior interferes with dtt's primary job. du -B reports whole numbers, so dtt -B reports whole numbers. But where du -B rounds up, dtt -B rounds to the nearest integer. This is where I felt strongly enough to make a change, because the legacy behavior is misleading. Your 131072-byte file is a case in point. On a volume having a blocksize of 4096 bytes, it reserves 32 blocks (131072 bytes) on the volume. When the reporting unit of measure is -B1M (binary megabytes), du reports the file reserves ~1 megabyte on the volume, and this is misleading. The number reported by dtt, ~0 megabytes, is much closer to the actual 0.125 megabytes reserved.
You can dedicate a single topic to that software of yours and then keep updating the first post with new information.
Actually, I can't do that. LQ freezes any post, including the first post of a thread, after some time, I believe it to be six months. Otherwise it's a good suggestion. Maybe I can rewrite the first post of this thread as a more release-independent intro, and then post new releases as replies beneath it. That is, if I get busy on it before the six month timer expires.
When the reporting unit of measure is -B1M (binary megabytes), du reports the file reserves ~1 megabyte on the volume, and this is misleading. The number reported by dtt, ~0 megabytes, is much closer to the actual 0.125 megabytes reserved.
When all your file sizes are rounded to 0 you may think your disk is empty and in the meantime probably your disk is full.
When all your file sizes are rounded to 0 you may think your disk is empty and in the meantime probably your disk is full.
Or you could use du, and when all your file sizes are rounded up to the next 1 megabyte, you may think your disk is full and in the meantime probably it's not.
The serious reply is, dtt subtotals and grand totals are calculated before rounding, so contributions of small files are never ignored. But also, normally you would use dtt to investigate a mount-point or a complex directory subtree such as /usr, not a single directory with 18 files in it. babydr picked a great test case for demonstrating and asking a specific question about dtt's rounding behavior. But it's not how you would use the tool. In a practical scenario you would not expect to see an output row rounded to 0.
Or you could use du, and when all your file sizes are rounded up to the next 1 megabyte, you may think your disk is full and in the meantime probably it's not.
obviously I don't want to use other tools, that would mean it is not good enough.
Quote:
Originally Posted by metaed
The serious reply is, dtt subtotals and grand totals are calculated before rounding, so contributions of small files are never ignored. But also, normally you would use dtt to investigate a mount-point or a complex directory subtree such as /usr, not a single directory with 18 files in it.
When you download for example the linux kernel (tgz) and unpack it you will get millions of files, most probably all of them are small (few kb). Using 1M as block size will cause what babydr explained, you have dirs (a lot), but it looks like all the files are empty everywhere. That is just odd, not a problem at all. Most probably you ought to use a sign like . or o instead of 0 to show it is not exactly 0, just rounded. (or 0+).
When you download for example the linux kernel (tgz) and unpack it you will get millions of files, most probably all of them are small (few kb). Using 1M as block size will cause what babydr explained, you have dirs (a lot), but it looks like all the files are empty everywhere
dtt's one job is to float the biggest chunks of disk usage to the top of its output, whether that's files or directory subtrees. So no, it won't clutter the report with individual little files. Here's how that actually looks:
Most probably you ought to use a sign like . or o instead of 0 to show it is not exactly 0, just rounded. (or 0+).
I think you are looking for human-friendly output. In that case you would use the option --human-readable instead of -B. When you use --human-readable, the question doesn't come up. This is because --human-readable already varies the reporting unit of measure automatically from bytes, to kilobytes, megabytes, gigabytes, etc. and also adds a decimal place where appropriate. So small files, if they get reported, get reported without rounding to 0.
Incidentally, the reason that utilities like df, du, and dtt offer options like -B is to support scripting. For that purpose, it actually is a hindrance to introduce prefixes and suffixes that may not be there. Because then the script would have to parse them. Scripting is simple when the input is simple, complicated when the input is complicated.
The beta fixes errors found in the 2.1 alpha release candidate. For details see the changelog. The 2.1 beta can be downloaded from https://metaed.com/papers/dtt/. (If you cannot reach the site, you are connecting from a country that is geoblocked because of high attack rate. At the moment that's CN, VN, RU, HK, SG, IN, KR, TW, BR, JP, and ID. Let me know which country and and I will lower shields for you.)
dtt is a utility that types a “top ten” report of directory trees and files found on a file-structured storage device, such as a Unix or Windows volume. In other words, it floats the really big chunks to the top.
dtt 2.2 is not a feature drop. It lays the groundwork for future development by simplifying many things about the build process, and also includes general source and documentation cleanup. For details see the dttlanding page, and the attached screenshots.
dtt is a better "where's my disk space" utility. It quickly summarizes filesystem usage into a "top ten" list of largest subtrees or individual objects. Its output has the unique property that it shows the ten largest single subtrees found at any depth without reporting redundant results. In other words, all the really big chunks float to the top. Sample output:
Subscribe this thread for release announcements such as the one below, and for feature requests and general discussion about the tool.
New in 2.1 alpha (release candidate):
added --inodes option
made option parsing errors fatal (thank you 0XBF)
added support for Perl 5.38.2
made lots of clarifying edits to the manuals
Release 2.1 alpha source package, Slackware 15.0 slackbuild, manuals, and changelog are here: https://metaed.com/papers/dtt/. (If you cannot reach the site, you are connecting from a country that is geoblocked because of high attack rate. At the moment that's CN, VN, RU, HK, SG, IN, KR, TW, BR, JP, and ID. Let me know which country and and I will lower shields for you.)
is there any way to make it available for other distros?
probably add -n|--number to print top N lines.
add short options, like -i|--inodes -a|--apparent-size -h|--help (or -?) -V|--version
and as it was mentioned would be nice to have either a ~/.dttrc for user specific defaults or an env var which may contain default options (like less).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
