我之前做得这么复杂 我相信这些命令实际上是更简单的方法，同时仍然很好地格式化一切。
RHEL 5 du -x / | sort -n |cut -d\/ -f1-2|sort -k2 -k1,1nr|uniq -f1|sort -n|tail -10|cut -f2|xargs du -sxh Solaris 10 du -d / | sort -n |cut -d\/ -f1-2|sort -k2 -k1,1nr|uniq -f1|sort -n|tail -10|cut -f2|xargs du -sdh RHEL5
du -x /|egrep -v "$(echo $(df|awk '{print $1 "\n" $5 "\n" $6}'|cut -d\/ -f2-5|egrep -v "[0-9]|^$|Filesystem|Use|Available|Mounted|blocks|vol|swap")|sed 's/ /\|/g')"|egrep -v "proc|sys|media|selinux|dev|platform|system|tmp|tmpfs|mnt|kernel"|cut -d\/ -f1-3|sort -k2 -k1,1nr|uniq -f1|sort -k1,1n|cut -f2|xargs du -sxh|egrep "G|[5-9][0-9]M|[1-9][0-9][0-9]M"|sed '$d'
的Solaris
du -d /|egrep -v "$(echo $(df|awk '{print $1 "\n" $5 "\n" $6}'|cut -d\/ -f2-5|egrep -v "[0-9]|^$|Filesystem|Use|Available|Mounted|blocks|vol|swap")|sed 's/ /\|/g')"|egrep -v "proc|sys|media|selinux|dev|platform|system|tmp|tmpfs|mnt|kernel"|cut -d\/ -f1-3|sort -k2 -k1,1nr|uniq -f1|sort -k1,1n|cut -f2|xargs du -sdh|egrep "G|[5-9][0-9]M|[1-9][0-9][0-9]M"|sed '$d'
这将以“递增”，“后退”，“可读”格式以及相当快的时间返回超过50MB的“/”文件系统中的目录。
要求：你能帮助使这个单线更有效，更快或更有效吗？ 如何更优雅？ 如果你明白我在那里做了什么，那么请继续阅读。
问题是要快速辨别“/”目录下包含的所有目录对“/”文件系统容量的贡献是很困难的，因为所有其他文件系统都属于根目录。
当在Solaris 10或者Red Hat el5上运行du时，通过从第二个pipe道分隔的egrep regex子shell排除中基本上消除一个egrepped df，这将排除所有非/文件系统，这自然被第三egrep排除在我想参考的为“鲸鱼”。 如果du -x / -d实际上是有用的（见下面的评论），那么最后的免费的egrep就会popup一个相关的高容量目录列表，这些目录完全包含在“/”文件系统，但不在其他安装的文件系统中。 这是非常草率的。
pwd = /
du *|egrep -v "$(echo $(df|awk '{print $1 "\n" $5 "\n" $6}'|cut -d\/ -f2-5|egrep -v "[0-9]|^$|Filesystem|Use|Available|Mounted|blocks|vol|swap")|sed 's/ /\|/g')"|egrep -v "proc|sys|media|selinux|dev|platform|system|tmp|tmpfs|mnt|kernel"|cut -d\/ -f1-2|sort -k2 -k1,1nr|uniq -f1|sort -k1,1n|cut -f2|xargs du -shx|egrep "G|[5-9][0-9]M|[1-9][0-9][0-9]M"
这是针对这些文件系统运行的：
Linux builtsowell 2.6.18-274.7.1.el5 #1 SMP Mon Oct 17 11:57:14 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux df -kh Filesystem Size Used Avail Use% Mounted on /dev/mapper/mpath0p2 8.8G 8.7G 90M 99% / /dev/mapper/mpath0p6 2.0G 37M 1.9G 2% /tmp /dev/mapper/mpath0p3 5.9G 670M 4.9G 12% /var /dev/mapper/mpath0p1 494M 86M 384M 19% /boot /dev/mapper/mpath0p7 7.3G 187M 6.7G 3% /home tmpfs 48G 6.2G 42G 14% /dev/shm /dev/mapper/o10g.bin 25G 7.4G 17G 32% /app/SIP/logs /dev/mapper/o11g.bin 25G 11G 14G 43% /o11g tmpfs 4.0K 0 4.0K 0% /dev/vx lunmonster1q:/vol/oradb_backup/epmxs1q1 686G 507G 180G 74% /rpmqa/backup lunmonster1q:/vol/oradb_redo/bisxs1q1 4.0G 1.6G 2.5G 38% /bisxs1q/rdoctl1 lunmonster1q:/vol/oradb_backup/bisxs1q1 686G 507G 180G 74% /bisxs1q/backup lunmonster1q:/vol/oradb_exp/bisxs1q1 2.0T 1.1T 984G 52% /bisxs1q/exp lunmonster2q:/vol/oradb_home/bisxs1q1 10G 174M 9.9G 2% /bisxs1q/home lunmonster2q:/vol/oradb_data/bisxs1q1 52G 5.2G 47G 10% /bisxs1q/oradata lunmonster1q:/vol/oradb_redo/bisxs1q2 4.0G 1.6G 2.5G 38% /bisxs1q/rdoctl2 ip-address1:/vol/oradb_home/cspxs1q1 10G 184M 9.9G 2% /cspxs1q/home ip-address2:/vol/oradb_backup/cspxs1q1 674G 314G 360G 47% /cspxs1q/backup ip-address2:/vol/oradb_redo/cspxs1q1 4.0G 1.5G 2.6G 37% /cspxs1q/rdoctl1 ip-address2:/vol/oradb_exp/cspxs1q1 4.1T 1.5T 2.6T 37% /cspxs1q/exp ip-address2:/vol/oradb_redo/cspxs1q2 4.0G 1.5G 2.6G 37% /cspxs1q/rdoctl2 ip-address1:/vol/oradb_data/cspxs1q1 160G 23G 138G 15% /cspxs1q/oradata lunmonster1q:/vol/oradb_exp/epmxs1q1 2.0T 1.1T 984G 52% /epmxs1q/exp lunmonster2q:/vol/oradb_home/epmxs1q1 10G 80M 10G 1% /epmxs1q/home lunmonster2q:/vol/oradb_data/epmxs1q1 330G 249G 82G 76% /epmxs1q/oradata lunmonster1q:/vol/oradb_redo/epmxs1q2 5.0G 609M 4.5G 12% /epmxs1q/rdoctl2 lunmonster1q:/vol/oradb_redo/epmxs1q1 5.0G 609M 4.5G 12% /epmxs1q/rdoctl1 /dev/vx/dsk/slaxs1q/slaxs1q-vol1 183G 17G 157G 10% /slaxs1q/backup /dev/vx/dsk/slaxs1q/slaxs1q-vol4 173G 58G 106G 36% /slaxs1q/oradata /dev/vx/dsk/slaxs1q/slaxs1q-vol5 75G 952M 71G 2% /slaxs1q/exp /dev/vx/dsk/slaxs1q/slaxs1q-vol2 9.8G 381M 8.9G 5% /slaxs1q/home /dev/vx/dsk/slaxs1q/slaxs1q-vol6 4.0G 1.6G 2.2G 42% /slaxs1q/rdoctl1 /dev/vx/dsk/slaxs1q/slaxs1q-vol3 4.0G 1.6G 2.2G 42% /slaxs1q/rdoctl2 /dev/mapper/appoem 30G 1.3G 27G 5% /app/em
这是结果：
Linux的：
54M etc/gconf 61M opt/quest 77M opt 118M usr/ ##===\ 149M etc 154M root 303M lib/modules 313M usr/java ##====\ 331M lib 357M usr/lib64 ##=====\ 433M usr/lib ##========\ 1.1G usr/share ##=======\ 3.2G usr/local ##========\ 5.4G usr ##<=============Ascending order to parent 94M app/SIP ##<==\ 94M app ##<=======Were reported as 7gb and then corrected by second du with -x.
=============================================
pwd = /
du *|egrep -v "$(echo $(df|awk '{print $1 "\n" $5 "\n" $6}'|cut -d\/ -f2-5|egrep -v "[0-9]|^$|Filesystem|Use|Available|Mounted|blocks|vol|swap")|sed 's/ /\|/g')"|egrep -v "proc|sys|media|selinux|dev|platform|system|tmp|tmpfs|mnt|kernel"|cut -d\/ -f1-2|sort -k2 -k1,1nr|uniq -f1|sort -k1,1n|cut -f2|xargs du -sh|egrep "G|[5-9][0-9]M|[1-9][0-9][0-9]M"
这是针对这些文件系统运行的：
SunOS solarious 5.10 Generic_147440-19 sun4u sparc SUNW,SPARC-Enterprise Filesystem size used avail capacity Mounted on kiddie001Q_rpool/ROOT/s10s_u8wos_08a 8G 7.7G 1.3G 96% / /devices 0K 0K 0K 0% /devices ctfs 0K 0K 0K 0% /system/contract proc 0K 0K 0K 0% /proc mnttab 0K 0K 0K 0% /etc/mnttab swap 15G 1.8M 15G 1% /etc/svc/volatile objfs 0K 0K 0K 0% /system/object sharefs 0K 0K 0K 0% /etc/dfs/sharetab fd 0K 0K 0K 0% /dev/fd kiddie001Q_rpool/ROOT/s10s_u8wos_08a/var 31G 8.3G 6.6G 56% /var swap 512M 4.6M 507M 1% /tmp swap 15G 88K 15G 1% /var/run swap 15G 0K 15G 0% /dev/vx/dmp swap 15G 0K 15G 0% /dev/vx/rdmp /dev/dsk/c3t4d4s0 3 20G 279G 41G 88% /fs_storage /dev/vx/dsk/oracle/ora10g-vol1 292G 214G 73G 75% /o10g /dev/vx/dsk/oec/oec-vol1 64G 33G 31G 52% /oec/runway /dev/vx/dsk/oracle/ora9i-vol1 64G 33G 31G 59% /o9i /dev/vx/dsk/home 23G 18G 4.7G 80% /export/home /dev/vx/dsk/dbwork/dbwork-vol1 292G 214G 73G 92% /db03/wk01 /dev/vx/dsk/oradg/ebusredovol 2.0G 475M 1.5G 24% /u21 /dev/vx/dsk/oradg/ebusbckupvol 200G 32G 166G 17% /u31 /dev/vx/dsk/oradg/ebuscrtlvol 2.0G 475M 1.5G 24% /u20 kiddie001Q_rpool 31G 97K 6.6G 1% /kiddie001Q_rpool monsterfiler002q:/vol/ebiz_patches_nfs/NSA0304 203G 173G 29G 86% /oracle/patches /dev/odm 0K 0K 0K 0% /dev/odm
这是结果：
Solaris上：
63M etc 490M bb 570M root/cores.ric.20100415 1.7G oec/archive 1.1G root/packages 2.2G root 1.7G oec
==============
如何能够更有效地处理跨多个平台的“/”又名“根”文件系统全部问题，这些问题具有破坏性的数量？
在Red Hat el5上，du -x显然避免了遍历其他文件系统。 虽然这可能是这样的，但如果从/目录运行它似乎没有做任何事情。
在Solaris 10上，等效标志是du -d，显然没有意外。
（我希望我刚刚做错了。）
你猜怎么了？ 这真的很慢。
根据我的理解，你的问题是， du正在进入其他文件系统（其中一些是networking或SAN挂载，花费很长时间来计算利用率）。
我恭敬地提出，如果你想监视文件系统的利用率， du是这个工作的错误工具。 你想df （你显然知道，因为你包括它的输出）。
parsingdf的输出可以帮助你定位你应该运行du特定文件系统，以确定哪些目录正在咀嚼你的所有空间（或者如果你幸运的话，完整的文件系统有一个特定的责任方，你可以告诉它的数字自己出去）。 在任何一种情况下，至less你会知道一个文件系统在满之前就已经被填满了（输出更容易parsing）。
简而言之：首先运行df ，然后如果您必须在任何文件系统上运行du （例如85％），以获得更具体的细节。
继续你的脚本， du的原因是不尊重你的-d （或-x ）标志是因为你问的问题：
# pwd / # du * (. . .etc. . .)
你正在要求du运行/ du -x /bin /home /sbin /usr /tmp /var等所有的东西 – du正在做你正在问的东西（给你这些东西的用法。如果其中一个参数碰巧是一个文件系统， du假设你知道你正在做什么，并给出该文件系统的用法，直到它find的第一个子安装。
这与du -x / （“告诉我/忽略任何子坐骑”）是截然不同的。
修复你的脚本*不要 cd到你正在分析的目录中，而是运行
du /path/to/full/disk | [whatever you want to feed the output through]
这个（或者你可能得到的任何其他build议）并不能解决你的两个核心问题：
您的监控系统是特设的
如果你想在生殖器官咬你之前就发现问题，你真的需要部署一个体面的监测平台 。 如果您在pipe理团队购买产品时遇到麻烦，请提醒他们正确的监控可以避免停机。
你的环境（正如你所猜测的）是一团糟
除了重build这个东西之外，没有太多的事要做 – 这是你作为SA 的工作，要站出来，做一个非常清晰，非常LOUD的商业案例，说明为什么系统需要一次一个地拆卸下来，被pipe理。
对于需要做什么来说，你似乎有一个相当不错的把握，但是如果你有任何问题要求他们，我们会尽力帮助你（我们不能为你做你的build筑，但我们可以回答概念性问题或实际的“我如何做X与监测工具Y ？”types的东西…
简单的答案：安装一个基础设施监控工具（如ZenOSS，Zabixx等）。
如果你正在寻找一些自定义的东西，也许你需要某种抽象层来处理奇怪的每台机器的差异，而不是每次都要手动pipe理它们。
我经常提出这个build议。 我主张用于临时磁盘使用情况计算的工具是ncdu工具 。 有一个--exclude标志可以多次指定。
有Solaris的打包版本（CSWncdu），或者您可以从源代码进行编译。 它简化了你正在做的大部分工作。
我想你正在寻找的东西就像ncdu 。 这将允许您停止遍历目录，同时仍然能够find磁盘正在被消耗的位置。
我会回应其他答案，说这是你的监测系统发现问题后使用的工具 – 这不是你想要非交互式使用的工具。 实际上，因为它是基于ncurses的，所以这样做会是一个混乱。 任何值得使用salt的系统pipe理员都会让你下载一个审查和简单的工具，以防止资源匮乏，像你所描述的那样一起攻击bash怪物。 它会使用更多的内存，更多的I / O，而且远比“禁止”的软件更危险。