UPDATE: Ich habe das alles unten gemacht, was cool ist, aber ich habe mir eine bessere Methode ausgedacht, um Verzeichnisse nach Inode-Verwendung zu sortieren:
du --inodes -S | sort -rh | sed -n \
'1,50{/^.\{71\}/s/^\(.\{30\}\).*\(.\{37\}\)$/\1...\2/;p}'
Und wenn Sie im selben Dateisystem bleiben möchten, tun Sie Folgendes:
du --inodes -xS
Hier ist ein Beispiel für eine Ausgabe:
15K /usr/share/man/man3
4.0K /usr/lib
3.6K /usr/bin
2.4K /usr/share/man/man1
1.9K /usr/share/fonts/75dpi
...
519 /usr/lib/python2.7/site-packages/bzrlib
516 /usr/include/KDE
498 /usr/include/qt/QtCore
487 /usr/lib/modules/3.13.6-2-MANJARO/build/include/config
484 /usr/src/linux-3.12.14-2-MANJARO/include/config
JETZT MIT LS:
Einige Personen gaben an, dass sie keine aktuellen coreutils haben und die Option --inodes für sie nicht verfügbar ist. Also, hier ist ls:
sudo ls -AiR1U ./ |
sed -rn '/^[./]/{h;n;};G;
s|^ *([0-9][0-9]*)[^0-9][^/]*([~./].*):|\1:\2|p' |
sort -t : -uk1.1,1n |
cut -d: -f2 | sort -V |
uniq -c |sort -rn | head -n10
Dies liefert mir ziemlich identische Ergebnisse wie der du
Befehl:
DU:
15K /usr/share/man/man3
4.0K /usr/lib
3.6K /usr/bin
2.4K /usr/share/man/man1
1.9K /usr/share/fonts/75dpi
1.9K /usr/share/fonts/100dpi
1.9K /usr/share/doc/arch-wiki-markdown
1.6K /usr/share/fonts/TTF
1.6K /usr/share/dolphin-emu/sys/GameSettings
1.6K /usr/share/doc/efl/html
LS:
14686 /usr/share/man/man3:
4322 /usr/lib:
3653 /usr/bin:
2457 /usr/share/man/man1:
1897 /usr/share/fonts/100dpi:
1897 /usr/share/fonts/75dpi:
1890 /usr/share/doc/arch-wiki-markdown:
1613 /usr/include:
1575 /usr/share/doc/efl/html:
1556 /usr/share/dolphin-emu/sys/GameSettings:
Ich denke, die include
Sache hängt nur davon ab, auf welches Verzeichnis das Programm zuerst schaut - weil sie die gleichen Dateien und fest verbunden sind. Irgendwie gefällt mir das Ding oben. Ich könnte mich jedoch irren - und ich begrüße die Korrektur ...
Die zugrunde liegende Methode ist, dass ich jeden ls
Dateinamen durch den darin enthaltenen Verzeichnisnamen ersetze. sed.
Darauf aufbauend ... Nun, ich bin selbst ein bisschen verschwommen. Ich bin mir ziemlich sicher, dass die Dateien genau gezählt werden, wie Sie hier sehen können:
% _ls_i ~/test
> 100 /home/mikeserv/test/realdir
> 2 /home/mikeserv/test
> 1 /home/mikeserv/test/linkdir
DU DEMO
% du --version
> du (GNU coreutils) 8.22
Erstellen Sie ein Testverzeichnis:
% mkdir ~/test ; cd ~/test
% du --inodes -S
> 1 .
Einige Kinderverzeichnisse:
% mkdir ./realdir ./linkdir
% du --inodes -S
> 1 ./realdir
> 1 ./linkdir
> 1 .
Machen Sie einige Dateien:
% printf 'touch ./realdir/file%s\n' `seq 1 100` | . /dev/stdin
% du --inodes -S
> 101 ./realdir
> 1 ./linkdir
> 1 .
Einige Hardlinks:
% printf 'n="%s" ; ln ./realdir/file$n ./linkdir/link$n\n' `seq 1 100` |
. /dev/stdin
% du --inodes -S
> 101 ./realdir
> 1 ./linkdir
> 1 .
Schauen Sie sich die Hardlinks an:
% cd ./linkdir
% du --inodes -S
> 101
% cd ../realdir
% du --inodes -S
> 101
Sie werden alleine gezählt, gehen aber ein Verzeichnis hoch ...
% cd ..
% du --inodes -S
> 101 ./realdir
> 1 ./linkdir
> 1 .
Dann habe ich mein Skript von unten ausgeführt und:
> 100 /home/mikeserv/test/realdir
> 100 /home/mikeserv/test/linkdir
> 2 /home/mikeserv/test
Und Graemes:
> 101 ./realdir
> 101 ./linkdir
> 3 ./
Ich denke, das zeigt, dass der einzige Weg, Inodes zu zählen, der Inode ist. Und weil das Zählen von Dateien das Zählen von Inodes bedeutet, können Sie Inodes nicht doppelt zählen - um Dateien genau zu zählen, können Inodes nicht mehr als einmal gezählt werden.
ALT:
Ich finde das schneller und es ist portabel:
sh <<-\CMD
{ echo 'here='"$PWD"
printf 'cd "${here}/%s" 2>/dev/null && {
set --
for glob in ".[!.]*" "[!.]*" ; do
set -- $glob "$@" &&
[ -e "./$1" ] || shift
done
printf "%%s\\t%%s\\n" $# "$PWD"
}\n' $( find . -depth -type d 2>/dev/null )
} | . /dev/stdin |
sort -rn |
sed -n \
'1,50{/^.\{71\}/s/^\(.\{30\}\).*\(.\{37\}\)$/\1...\2/;p}'
CMD
Es muss nicht -exec
für jedes Verzeichnis gelten - es werden nur der eine sh
und der eine Ell-Prozess verwendet find
. Ich muss noch das set -- $glob
Recht bekommen , .hidden
Dateien und alles andere einzuschließen, aber es ist sehr nah und sehr schnell. Du würdest einfach cd
in was auch immer dein Root-Verzeichnis sein soll für die Prüfung und los geht's.
Hier ist ein Beispiel meiner Ausgabe von /usr
:
14684 /usr/share/man/man3
4322 /usr/lib
3650 /usr/bin
2454 /usr/share/man/man1
1897 /usr/share/fonts/75dpi
...
557 /usr/share/gtk-doc/html/gtk3
557 /usr/share/doc/elementary/latex
539 /usr/lib32/wine/fakedlls
534 /usr/lib/python2.7/site-packages/bzrlib
500 /usr/lib/python3.3/test
Ich benutze dort auch sed
am unteren Rand, um es auf die oberen 50 Ergebnisse zu trimmen. head
wäre natürlich schneller, aber ich schneide bei Bedarf auch jede Zeile zu:
...
159 /home/mikeserv/.config/hom...hhkdoolnlbekcfllmednbl/4.30_0/plugins
154 /home/mikeserv/.config/hom...odhpcledpamjachpmelml/1.3.11_0/js/ace
...
Zugegeben, es ist grob, aber es war ein Gedanke. Ein anderes rohes Gerät, das ich benutze, ist das Dumping 2>stderr
für beide find
und cd
in 2>/dev/null
. Es ist nur sauberer, als sich Berechtigungsfehler für Verzeichnisse anzusehen, die ich ohne Root-Zugriff nicht lesen kann - vielleicht sollte ich das spezifizieren find
. Nun, es ist eine laufende Arbeit.
Ok, also habe ich die Shell-Globs folgendermaßen repariert:
for glob in ".[!.]*" "[!.]*" ; do
set -- $glob "$@" &&
[ -e "./$1" ] || shift
done
Eigentlich wollte ich eine Frage stellen, wie es gemacht werden könnte, aber als ich den Fragentitel eintippte, verwies mich die Site auf eine vorgeschlagene verwandte Frage , in die Stephane bereits eingewogen hatte . Das war praktisch. Anscheinend ist es [^.],
zwar gut unterstützt, aber nicht tragbar und man muss das benutzen, was !bang.
ich in Stephanes Kommentar dort gefunden habe.
Auf jeden Fall war es offensichtlich nicht genug, nur versteckte Dateien einzulesen. Ich muss also set
zweimal suchen, um zu vermeiden, dass nach dem Wortlaut gesucht wird $glob
. Trotzdem scheint es die Leistung überhaupt nicht zu beeinträchtigen, und es fügt zuverlässig jede Datei im Verzeichnis hinzu.