petabyte veri setinde 'du' raporlarını optimize etmek?

Birkaç Petabayt genomik verisinin veri kümesi hakkında günlük bir dosya boyutu raporu almaya çalışıyorum. Mevcut raporumuzda birden fazla çakışma var du sonucu elde etmek için yapılan çağrılar, ancak yürütülmesi 24 saatten fazla sürüyor. Bunu daha verimli / hızlı / 'temiz' yapmanın bir yolunu arıyorum.

şu anda yapıyoruz:

# 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/

Beni rahatsız eden şey bu special_project_[ABC] Ayrıntılı görünüm için bir kez genel toplam görünümde bir kez iki kez taranır. Bu özel projeler büyük miktarda veriyi oluşturduğundan, onları iki kez taramak muhtemelen (uyarı: varsayım) çalışma zamanının önemli bir parçası. Ayrıca, petabaytlardan bahsettiğimizden, herhangi bir dosya sistemi önbelleğe alma düzeyinin tekrarlanan çağrıları hızlandıracağına inanmıyorum.

'Optimizasyonu' denedim du -d1 /petastorage/projects/ /petastorage/projects/special_project_[ABC]/ ama görünüyor du Özel projelerin ilk dizinin alt dizinleri olduğunu anlayacak kadar akıllıdır ve bu yüzden onları raporlamadan 'optimize eder'. Gah!

Nasıl ikna edebileceğim konusunda fikri olan var mı? du Petabitlerimi yalnızca bir kez tarayarak, hem tüm projeleri tek tek hem de üç 'özel projenin' (bir seviye-derin) ayrıntı görünümünü ortaya çıkaran

not: Geçerli du-çıktı, e-posta raporunda daha iyi ve yinelenmeyen bir şekilde görüntülenmesini sağlamak için halihazırda bir dizi / uniq boru tesisatı içine alınmış olduğundan, işleme sonrası işlemleri içeren çözümler kabul edilebilir. İşleme sonrası herhangi bir çalışma zamanı, eğirme pasının statting statata kıyasla sıfırdır.

Önemli olması durumunda arka plan: bu, OpenSuse 11.4'e monte edilmiş EMC-isilon depolama düğümlerine bir NFSv3 montajıdır. Tüm projeler şu anda adalardaki tek bir depolama havuzunu paylaşıyor, böylece projeler arasında boş alan değiştirilebiliyor. 'Özel' projeleri kendi dosya sistemlerine taşımak, böylece 'hile yapabiliriz' df boyutları nedeniyle mümkün değildir.

Bu konuda bir veya iki gün harcadıktan sonra, kolay yoldan gitmeye karar verdik ve şu an için daha fazla optimizasyon yapmayacağız. Sonunda, geliştirici zamanı komut dosyası çalıştırma süresinden daha maliyetlidir.

Eğer / bu konuya geri döndüğümde, muhtemelen bir tane yapacağım du alt projeler için koşmak, ikinci du büyük klasörler için çalıştır --exclude Birinci kapsamındaki projelerde) ve genel toplamı elle işlem sonrası birlikte hesaplamak (yargısal kullanımı awk, sedveya grep | paste -sd'+' | bc yeterli olmalı

Başka birinin daha iyi fikirleri varsa, onları duyduğuma sevinirim :-)

Geri bildirmek için, depolamamızın daha büyük bir yeniden mimarisinin bir parçası olarak “uygulanamaz” rotaya gittik.

Yeni dosya sunucularımız alt montaj başına kotayı desteklemektedir, bu nedenle zaman içinde büyük, paylaşılan bir dosya sisteminde / montajında ​​"normal" klasörler yerine projeleri alt montajlara çıkardık. Bu, birkaç hafta / ay boyunca bir brülör göç projesiydi. Bu, istenen tüm "klasörler" üzerine kota koymamızı sağlamıştır.

Şimdi kota durumunu sorguluyoruz (ki bunlar canlı ve anında dosya sunucuları tarafından yönetilir)