оптимизировать отчеты du для набора петабайтных данных?

Question

Я пытаюсь получить ежедневный отчет о размере файла из нескольких петабайт данных геномики. Наш текущий отчет использует несколько перекрывающихся вызовов du для достижения результата, но для его выполнения требуется более 24 часов. Я ищу способ сделать это более эффективно / быстро / "чисто".

В настоящее время мы делаем:

# broad overview of dozens of projects + grand total
du -chd1 /petastorage/projects/  

# detailed look at some 'special' projects, 
# each of these has huge sub-dirs we want to track individually
du -hd1 /petastorage/projects/special_project_A/
du -hd1 /petastorage/projects/special_project_B/
du -hd1 /petastorage/projects/special_project_C/

Меня беспокоит то, что special_project_[ABC] сканируется дважды, один раз в общем обзоре, один раз для подробного просмотра. Поскольку на эти специальные проекты приходится большая часть данных, их обход в два раза, вероятно, (предупреждение: предположение) является важной частью времени выполнения. Кроме того, поскольку мы говорим о петабайтах, я не верю, что какой-либо уровень кэширования файловой системы ускорит повторные вызовы.

Я попытался «оптимизировать» до du -d1 /petastorage/projects/ /petastorage/projects/special_project_[ABC]/ но кажется, что du достаточно умен, чтобы понять, что специальные проекты являются дочерними каталогами первого каталога, и поэтому «оптимизирует» их из отчетности. Г!

Кто-нибудь знает, как я могу убедить du сканировать свои петабайты только один раз, выводя как все проекты по отдельности, так и подробное представление (на один уровень глубже) трех «специальных проектов»

примечание: текущий вывод du уже пропущен через какую-то трубу sort/uniq, чтобы он отображался лучше и без дубликатов в отчете по электронной почте, поэтому приемлемы решения, связанные с постобработкой. Любая длительность постобработки равна нулю по сравнению с составлением петабайт вращающейся ржавчины.

Предыстория на случай, если это имеет значение: это монтирование NFSv3 к узлам хранения EMC-isilon, смонтированным в OpenSuse 11.4. Все проекты в настоящее время совместно используют один пул хранения на isilons, поэтому свободное пространство можно распределять между проектами. Перемещение «специальных» проектов в их собственные файловые системы, чтобы мы могли «обманывать» с помощью df , невозможно из-за их размера.

Answer 1

Чтобы отчитаться, мы с тех пор пошли по "неиссякаемому" маршруту в рамках более масштабной реорганизации нашего хранилища.

Наши новые файловые серверы поддерживают квоту на подмонтирование, поэтому со временем мы извлекали проекты в субмонтирования вместо "обычных" папок в большой общей файловой системе / монтировании. Это был задний ход проекта миграции в течение нескольких недель / месяцев. Это позволило нам установить квоту на все нужные "папки".

Теперь мы запрашиваем статус квоты (который управляется в реальном времени и мгновенно файловыми серверами)

Answer 2

Потратив (объединенный) день или два на эту проблему, мы решили пойти легким путем, а не оптимизировать сейчас. В конце концов, время разработки обходится дороже, чем время выполнения скрипта.

Если / Когда я вернусь к этому вопросу, я , вероятно , сделать один du баллотироваться подпроектами, вторые du запуск для больших папок (с --exclude по проектам , охватываемых первым), и вручную вычислить общий итог вместе в постобработке (достаточно разумного использования awk , sed или grep | paste -sd'+' | bc )

Если у кого-то есть идеи получше, я буду рад их услышать :-)