Karışık Disklerde En Hızlı Linux Dosya Sistemi

Karıştırılmış sürücülere büyük ilgi var. Bunlar veri izlerini birbirine o kadar yakın koyar ki, bir sonraki parçaya engel olmadan bir parçaya yazamazsınız. Bu kapasiteyi% 20 oranında artırabilir, ancak yazma amplifikasyonu sorunlarına yol açar. Shingled sürücüler için optimize edilmiş dosya sistemlerinde devam eden çalışmalar var, örneğin bakınız: https://lwn.net/Articles/591782/

Seagate 8TB arşivi gibi bazı karışık disklerde, rasgele yazma işlemleri için önbellek alanı bulunur ve bu da genel dosya sistemlerinde iyi performans sağlar. Disk, 200MB / sn'ye kadar yuvarlak yazma gibi bazı genel iş yüklerinde bile oldukça hızlı olabilir. Ancak, rastgele yazma önbelleğinin taşması durumunda performansın düşebileceği beklenmelidir. Muhtemelen, bazı dosya sistemleri genel olarak rastgele yazmalardan veya bu sürücülerde bulunan yazma önbelleğini taşması muhtemel rastgele yazma kalıplarından kaçınmak için daha iyidir.

Linux çekirdeğindeki anaakım bir dosya sistemi , shingled disklerin performans cezalarından ext4'ten daha iyi mi?

Sezgisel olarak Yazarak Kopyala ve Günlüğe Kaydet yapılandırılmış dosya sistemleri, rastgele yazma işlemlerini azaltmayı azaltarak shingled disklerde daha iyi performans verebilir. Karşılaştırma ölçütleri bunu bir şekilde desteklemektedir, ancak performanstaki bu farklılıklar karışık disklere özgü değildir. Ayrıca, denetim olarak kullanılan shingled disk üzerinde de oluşurlar. Bu nedenle, karışık bir diske geçmek, dosya sistemi seçiminizle pek alakalı olmayabilir.

Nilfs2 dosya sistemi SMR disk üzerinde oldukça iyi performans verdi. Ancak, bunun nedeni, tüm 8 TB bölümünü ayırdım ve kıyaslama yalnızca ~ 0.5 TB yazdı, böylece nilfs temizleyicinin çalışması gerekmiyordu. Bölümü 200 GB ile sınırlandırdığımda, nilfs kriterleri başarıyla tamamlanmadı. "Arşiv" diskini gerçekten bir arşiv diski olarak kullanırsanız, o zaman nilfs temizleyicinin çalıştırılması gerekmediği için Nilfs2 iyi bir seçim olabilir.

ST8000AS0002-1NA17ZTest için kullandığım 8 TB'lık seagate diskinin ~ 20GB önbellek alanına sahip olduğunu anlıyorum . Ayarlanan karşılaştırmalar ~ 125GB, shshled önbellek alanından daha büyük olacak şekilde varsayılan filebench dosya sunucusu ayarlarını değiştirdim:

set $meanfilesize=1310720
set $nfiles=100000
run 36000

Şimdi gerçek veriler için. Ops sayısı "genel" dosya sunucusu performansını, ms / op ise rastgele ekin gecikmesini ölçer ve rastgele yazmaların performansı için kabaca bir rehber olarak kullanılabilir.

$ grep rand *0.out | sed s/.0.out:/\ / |sed 's/ - /-/g' |  column -t
SMR8TB.nilfs   appendfilerand1   292176ops 8ops/s   0.1mb/s   1575.7ms/op    95884us/op-cpu [0ms - 7169ms]
SMR.btrfs      appendfilerand1  214418ops  6ops/s   0.0mb/s  1780.7ms/op  47361us/op-cpu  [0ms-20242ms]
SMR.ext4       appendfilerand1  172668ops  5ops/s   0.0mb/s  1328.6ms/op  25836us/op-cpu  [0ms-31373ms]
SMR.xfs        appendfilerand1  149254ops  4ops/s   0.0mb/s  669.9ms/op   19367us/op-cpu  [0ms-19994ms]
Toshiba.btrfs  appendfilerand1  634755ops  18ops/s  0.1mb/s  652.5ms/op   62758us/op-cpu  [0ms-5219ms]
Toshiba.ext4   appendfilerand1  466044ops  13ops/s  0.1mb/s  270.6ms/op   23689us/op-cpu  [0ms-4239ms]
Toshiba.xfs    appendfilerand1  368670ops  10ops/s  0.1mb/s  195.6ms/op   19084us/op-cpu  [0ms-2994ms]

Seagate 5980 RPM olduğu için Toshiba'nın% 20 daha hızlı olması beklenebilir. Bu kriterler kabaca 3 kat (% 200) daha hızlı olduğunu gösteriyor, bu yüzden bu kriterler karışık performans cezasına çarpıyor. Shingled (SMR) diskinin hala shedled (PMR) diskteki ext4 performansıyla eşleşemediğini görüyoruz. En iyi performans, 8 TB bölümlü nilfs2 ile oldu (böylece temizleyicinin çalışması gerekmiyordu), ancak o zaman bile ext4 ile Toshiba'dan önemli ölçüde daha yavaştı.

Yukarıdaki karşılaştırmaları daha net hale getirmek için, her diskteki ext4'ün performansına göre bunları normalleştirmeye yardımcı olabilir:

                ops     randappend
SMR.btrfs:      1.24    0.74
SMR.ext4:       1       1
SMR.xfs:        0.86    1.98
Toshiba.btrfs:  1.36    0.41
Toshiba.ext4:   1       1
Toshiba.xfs:    0.79    1.38

SMR diskinde btrfs'nin ext4'te sahip olduğu genel op'larda avantajının çoğuna sahip olduğunu görüyoruz, ancak rastgele ekler üzerindeki ceza bir oran kadar dramatik değil. Bu, SMR diskindeki btrfs'ye geçmeye yol açabilir. Öte yandan, düşük gecikmeli rastgele eklere ihtiyacınız varsa, bu karşılaştırma ölçütü özellikle SMR'de xfs istediğinizi önerir. SMR / PMR'nin dosya sistemi seçiminizi etkileyebilmesine rağmen, optimize ettiğiniz iş yükü göz önüne alındığında daha önemli göründüğünü görüyoruz.

Ayrıca tavan arası bir kıyaslama yaptım. Tavan arası çalışmalarının süreleri (8 TB SMR tam disk bölümlerinde):

ext4:  1 days 1 hours 19 minutes 54.69 seconds
btrfs: 1 days 40 minutes 8.93 seconds
nilfs: 22 hours 12 minutes 26.89 seconds

Her iki durumda da çatı depoları aşağıdaki istatistiklere sahipti:

                       Original size      Compressed size    Deduplicated size
This archive:                1.00 TB            639.69 GB            515.84 GB
All archives:              901.92 GB            639.69 GB            515.84 GB

Aynı 1 TB diskinin ikinci bir kopyasını tavan arasına eklemek, bu üç dosya sisteminin her birinde 4,5 saat sürdü. Kıyaslamalar ve smartctlbilgilerin çiğ bir dökümü şuradadır : http://pastebin.com/tYK2Uj76 https://github.com/gmatht/joshell/tree/master/benchmarks/SMR

Eğer rsync gelen bir SMR sürücü dosya sistemi monte olduğundan emin olun read-onlyveya noatimeseçenek.

Aksi takdirde, SMR sürücüsünün rsync'in okuduğu her dosya için bir zaman damgası yazması gerekir, bu da performansta önemli bir düşüş (80 mb / s'den 3-5 mb / s'ye kadar) ve kafa aşınması / tıklatma gürültüsü ile sonuçlanır.

Zaten düşük performansla çalışan bir rsync işiniz varsa, durdurmaya gerek yoktur, kaynak dosya sistemini yeniden bağlayabilirsiniz.

sudo mount -o remount,ro  /path/to/source/fs

Etki hemen görülmeyecek, sabırlı olun ve sürücü hala arabelleklerindeki tüm verileri yazmayı bitirene kadar 10 ila 20 dakika bekleyin. Bu tavsiye denenmiş ve test edilmiştir.

Bu aynı zamanda geçerli olabilir rsyncing için dosya sistemi dosya tamamen diske yazıldıktan sonra zaman damgası güncelleştirmek çalışırsa yani bir SMR sürücüsüne. Bu, sıralı iş yükünü ve devasa veri bantlarını sürekli olarak yeniden yazarak sürücü aşınmasına katkıda bulunur. Aşağıdakiler yardımcı olabilir :

sudo mount -t fs_type -o rw,noatime device /path/to/dest/fs

Bu rsync çalıştırılmadan önce yapılmalıdır; diğer faktörler bu seçeneği önemsiz hale getirebilir, yani arabelleklenmemiş FAT / MFT güncellemesi, dosya sistemi öncelikle SSD'ler için optimize edilmişse paralel yazıyor.

dd bs=32MYine de tam dosya sistemlerini yedeklemek istiyorsanız (bu durumda her dosyayı taşımak için rsync'i yüklemenize ve çalıştırmanıza gerek yoksa) SMR hedefindeki dosya sistemini kullanmaya ve yeniden boyutlandırmaya çalışın .

Kullanılan gerçek donanım, Seagate disk yönetimli SMR 8 tb tüketici diskiydi. Km'niz diğer donanıma göre değişebilir.