सहज रूप से कॉपी-ऑन-लिखें और लॉग संरचित फाइलसिस्टम यादृच्छिक लेखन को कम करके शिंगल डिस्क पर बेहतर प्रदर्शन दे सकते हैं। बेंचमार्क कुछ हद तक इसका समर्थन करते हैं, हालांकि, प्रदर्शन में ये अंतर छितरी हुई डिस्क के लिए विशिष्ट नहीं हैं। वे एक नियंत्रण के रूप में उपयोग की जाने वाली एक अनडिस्लिंग डिस्क पर भी होते हैं। इस प्रकार एक shingled डिस्क पर स्विच करने से आपकी फ़ाइल सिस्टम की पसंद की अधिक प्रासंगिकता नहीं हो सकती है।
Nilfs2 फाइलसिस्टम ने SMR डिस्क पर काफी अच्छा प्रदर्शन दिया। हालाँकि, ऐसा इसलिए था क्योंकि मैंने पूरे 8TB विभाजन को आवंटित कर दिया था, और बेंचमार्क में केवल ~ 0.5TB लिखा था, इसलिए nilfs क्लीनर को चलाना नहीं था। जब मैंने विभाजन को 200GB तक सीमित कर दिया तो nilfs बेंचमार्क भी सफलतापूर्वक पूरा नहीं हुआ। Nilfs2 एक अच्छा विकल्प प्रदर्शन-वार हो सकता है यदि आप वास्तव में "आर्काइव" डिस्क को एक आर्काइव डिस्क के रूप में उपयोग करते हैं, जहां आप डिस्क पर लिखे गए सभी डेटा और स्नैपशॉट को हमेशा के लिए रखते हैं, तो तब नीलोफ क्लीनर को चलाना नहीं पड़ता है।
मैं समझता हूं कि ST8000AS0002-1NA17Zपरीक्षण के लिए मैंने जो 8TB सीगेट ड्राइव का उपयोग किया है, उसमें ~ 20GB कैश क्षेत्र है। मैंने डिफॉल्ट फाइलबेंच फाइलसेवर सेटिंग्स को बदल दिया ताकि बेंचमार्क सेट ~ 125GB हो, जो अनशिंक कैश एरिया से बड़ा हो:
set $meanfilesize=1310720
set $nfiles=100000
run 36000
अब वास्तविक आंकड़ों के लिए। ऑप्स की संख्या "समग्र" फाइलरवर के प्रदर्शन को मापती है जबकि ms / op यादृच्छिक परिशिष्ट की विलंबता को मापता है, और यादृच्छिक लेखन के प्रदर्शन के लिए किसी न किसी गाइड के रूप में इस्तेमाल किया जा सकता है।
$ 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]
चूंकि सीगेट 5980 आरपीएम है, इसलिए कोई व्यक्ति तोशिबा से 20% तेजी से उम्मीद कर सकता है। ये बेंचमार्क इसे लगभग 3 गुना (200%) तेजी से दिखाते हैं, इसलिए ये बेंचमार्क शिंगल परफॉर्मेंस पेनल्टी मार रहे हैं। हम देखते हैं कि शिंगल्ड (SMR) डिस्क अभी भी प्रदर्शन को किसी unshingled (PMR) डिस्क पर मिलान नहीं कर सकता है। सबसे अच्छा प्रदर्शन एक 8TB विभाजन के साथ nilfs2 के साथ था (इसलिए क्लीनर को चलाने की आवश्यकता नहीं थी), लेकिन फिर भी यह ext4 के साथ तोशिबा की तुलना में काफी धीमा था।
बेंचमार्क को अधिक स्पष्ट बनाने के लिए, प्रत्येक डिस्क पर ext4 के प्रदर्शन के सापेक्ष उन्हें सामान्य करने में मदद मिल सकती है:
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 डिस्क पर btrfs को कुल ऑप्स पर सबसे अधिक फायदा होता है, जो ext4 पर होता है, लेकिन रैंडम अपेंडिक्स पर जुर्माना एक अनुपात के रूप में नाटकीय नहीं है। यह SMR डिस्क पर btrfs पर जाने के लिए एक ले सकता है। दूसरी ओर, यदि आपको कम विलंबता यादृच्छिक अपेंडिक्स की आवश्यकता है, तो यह मानदंड बताता है कि आप एक्सएफएस चाहते हैं, खासकर एसएमआर पर। हम देखते हैं कि एसएमआर / पीएमआर फाइल सिस्टम की आपकी पसंद को प्रभावित कर सकता है, लेकिन उस कार्यभार को देखते हुए जो आपके लिए अधिक महत्वपूर्ण लगता है।
मैंने एक अटारी आधारित बेंचमार्क भी चलाया। अटारी रन की अवधि (8 टीबी एसएमआर पूर्ण डिस्क विभाजन पर) थीं:
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
प्रत्येक मामले में अटारी रिपॉजिटरी में निम्नलिखित आँकड़े थे:
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
अटारी के लिए एक ही टीबी डिस्क की दूसरी प्रति जोड़ने से इन तीन फाइल सिस्टमों में से प्रत्येक पर 4.5 घंटे लगते हैं। बेंचमार्क और smartctlजानकारी का एक कच्चा डंप इस प्रकार है:
http://pastebin.com/tYK2Uj76
https://github.com/gmatht/joshell/tree/master/benchmark/SMR