offline du, выбор пути реализации

Помнится, в ТоталКоммандере был плагинчик, который позволял генерировать файл по ФС и дальше заходить в этот файл как в архив и бродить по нему.

С первого приближения, можно грепом и седом забабахать.

А чего бы тебе не зайти по телнету на этот NAS (скажем, у сигейтовских насов есть дыра в пыхпыхе, позволяющая запускать всякую фигню через веб-морду), да выполнить du?

Можно по крону там это забульбенить, чтобы в каждой директории создавался "скрытый" файлик с размером этой директории.

ещё проще забабахать свой объект в snmp сервера, но опу фантазии не хватит

netapp — нет там du

anonymous ignored

а сразу не мог сказать, что там netapp вместо хранилища?

Ну и делать например du для всего NAS по крону раз в N времени и сохранять в файл/несколько файлов. По необходимости уже разбирать этот файл для определённой ветви. Можно гзипнуть этот файл, должно сильно помочь. Можно отсортировать по алфавиту имена директорий и делать бинарный поиск.

в примере только один volume этого NASa, find по нему работал не менее 6 часов

Вот и пусть работает потихоньку в фоне, как до конца доработает заменит файл.

вопрос в эффективной обработке, а не получении этого исходного файла.

du не катит.

вопрос в эффективной обработке,

А как его нужно обработать-то? Из списка файлов получить размеры каждой директории? Но сам список может меняться, новые файлы появляются, старые удаляются/перезаписываются.

Да и эффективнее чем stat вряд ли удастся вытащить размеры по NFS(можно конечно в несколько потоков, но сложно и неизвестно насколько быстрее будет)

У меня есть однострочник, который из списка файлов формирует список размеров директорий, вроде такого:

% find /etc | perl -we 'my %h;while(<STDIN>){chomp;my$s=$ARGV[0]?-s$_||0:1;my@p;@_=split"/",$_,       ($ARGV[1]||4)+2||4;pop@_;for(@_){push@p,$_;$h{join"/",@p}+=$s}};my$p;for my$k(sort{$a  cmp$b}keys%h){$_=$k;for my$c(split"/",$p){$c||next;s#^/\Q$c\E## or$_=$k and last};$_=("."x length$p).$_ if$_ ne$k;$p=$k;$p=~s#/[^/]*$##;printf"%-12i %s\n",$h{$k},$_}' 1

14204557     
14200461     /etc
200148       /etc/ImageMagick-6
2661         ..../UPower
15519        ..../X11
5679         ..../X11/xinit
712          ......../xinit/xinitrc.d
1648         /etc/X11/xorg.conf.d
53           /etc/adobe
1335         ..../at-spi2
62188        ..../ati
14376        ..../avahi
2146         ..../avahi/services
1803212      /etc/ca-certificates
1786828      ..../ca-certificates/extracted
1057278      ..................../extracted/cadir
8192         /etc/ca-certificates/trust-source
841          /etc/conf.d
180          ..../cron.d
392          ..../cron.hourly
131          ..../cups
51843        ..../dbus-1
37787        ..../dbus-1/system.d
1023         /etc/default
145440       ..../fonts
66293        ..../fonts/conf.avail
58214        ........../conf.d

https://metacpan.org/pod/Filesys::DiskUsage::Fast

нужно почистить NAS от скопившегося барахла. Как это делают? Смотрим первый уровень какие директории сколько занимают, du при этом сканирует все файлы какие есть. спускаемся в одну из них и снова запускаем du, он снова сканирует все файлы в этой ветке дерева, хотя при первом запуске он тут уже был. все это лишняя и долгая работа, кеширование не помогает на таких объемах.

Давайте примем за основу: исходный материал вышеуказанный текстовый файл — результат html статика одна страница для каждой директории, так можно будет ходить по ним оффлайн. процедура условно будет запускаться раз в год.

не читабельно, мне проще самому написать, чем это парсить

Там тот же однопоточный последовательный lstat в XS коде. На быстрых локальных дисках будет быстрее (c вместо perl), а на сетевом хранилище всё так же упрётся в сеть. С тем же успехом можно du запускать

Ну тогда есть два варианта. Первый - добыть размеры всех файлов заранее, сохранить в файл (условно du -b /stor > ~/file) и потом почти мгновенно скриптом считать размеры по этому файлу (если сам список файлов 1.7Гб, то список с размерами займёт примерно стоклько же. Бинарный поиск найдёт интересующую строку за 20-40 seek, таким образом размер любой директории можно будет достать за менее секунды-несколько секунд).

Второй вариант - делать свой du по списку файлов, который будет кешировать промежуточные результаты в файл и не пересчитывать их заново. Так даже проще, в первый раз можно будет запустить его неинтерактивно, чтобы он прокешировал в файл всё хранилище. Но для эффективного поиска по всему хранилищу так же понадобится бинарный поиск.

У тебя 5 звезд - запили драйвер ФС в ядро. ФС будет хранить только метаданные файлов.

у меня 15.5 звезд, мне запилить свое ядро с блэкджеком и анонимусами?

15.5 не хватит. По теме - ищи, может кто-то уже делал такую ФС. Как вариант, можно покрутить что-то типа tar или iso формат, которые можно маунтить в Линухе.

С tar файлом можно сделать такую штуку - делаем пробег по ФС и формируем tar файл, но вместо содержимого файлов кидаем нули. При этом, если в твоей ФС включена возможность делать разреженные файлы, то результирующий tar не займет много места. Дальше маунтим его и работаем как с полноценной ФС.

Такая байда с tar пишется за несколько часов.

я решил что мне нужны html, лично я не буду заниматься чисткой системы. будет хелпдеск, который боится консоли, но может поползать по веб-страничкам для поиска жирных директорий и поиска их владельцев

потом через fuse будет тормозить, спасибо не надо