Próbuję uzyskać codzienny raport wielkości pliku dotyczący zestawu danych kilku petabajtów danych genomicznych. Nasz bieżący raport wykorzystuje wiele nakładających się du
wywołań, aby osiągnąć wynik, ale jego wykonanie zajmuje ponad 24 godziny. Szukam sposobu, aby to zrobić bardziej wydajnie / szybko / „czysto”.
obecnie wykonujemy:
# 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/
Niepokoi mnie to, że special_project_[ABC]
są indeksowane dwa razy, raz w ogólnym podsumowaniu, raz dla szczegółowego wyglądu. Ponieważ te specjalne projekty stanowią dużą część danych, przeszukanie ich dwukrotnie stanowi prawdopodobnie (ostrzeżenie: założenie) znaczną część środowiska wykonawczego. Ponadto, ponieważ mówimy o petabajtach, nie sądzę, aby poziom buforowania systemu plików przyspieszył powtarzanie wywołań.
Próbowałem „zoptymalizować”,
du -d1 /petastorage/projects/ /petastorage/projects/special_project_[ABC]/
ale wydaje się, że du
jest wystarczająco inteligentny, aby zdać sobie sprawę, że projekty specjalne są katalogami potomnymi pierwszego katalogu, a zatem „optymalizuje” je z raportowania. Gah!
Czy ktoś ma pomysł, w jaki sposób mogę przekonać mnie du
do indeksowania moich petabajtów tylko raz, generując zarówno wszystkie projekty indywidualnie, jak i (szczegółowy widok) trzech „projektów specjalnych”
Uwaga: obecny du-output jest już przepuszczany przez jakiś potok sortowania / uniq, aby wyświetlał się ładniej i bez duplikatów w raporcie e-mail, więc rozwiązania obejmujące przetwarzanie końcowe są dopuszczalne. Każdy czas przetwarzania końcowego jest równy zeru w porównaniu do rejestrowania petabajtów wirującej rdzy.
Tło w przypadku, gdy ma to znaczenie: jest to podłączenie NFSv3 do węzłów pamięci EMC-isilon, zamontowane na OpenSuse 11.4. Wszystkie projekty obecnie współużytkują jedną pulę pamięci w isilons, więc wolne miejsce można przesuwać między projektami. Przenoszenie „specjalnych” projektów do ich własnych systemów plików, abyśmy mogli „oszukiwać” df
jest niemożliwe ze względu na ich rozmiar.