इस वसंत में, हमने पहले से ही कुछ परिचयात्मक विषयों पर चर्चा की है, जैसे कि आपके डिस्क की गति की जांच कैसे करें और RAID क्या है । उनमें से दूसरे में, हमने ZFS में विभिन्न मल्टी-डिस्क टोपोलॉजी के प्रदर्शन का अध्ययन जारी रखने का भी वादा किया। यह अगली पीढ़ी की फ़ाइल प्रणाली है जिसे हर जगह लागू किया जा रहा है: Apple से Ubuntu तक ।

खैर, आज सबसे अच्छा दिन है ZFS, जिज्ञासु पाठकों को जानने का। बस इस बात से अवगत रहें कि OpenZFS डेवलपर मैट आर्न्स द्वारा एक रूढ़िवादी मूल्यांकन के अनुसार, "यह वास्तव में जटिल है।"

लेकिन इससे पहले कि हम संख्याओं तक पहुँचें - और वे करेंगे, मैं वादा करता हूँ - सभी वेरिएंट vosmidiskovoy ZFS कॉन्फ़िगरेशन के लिए, आपको डिस्क पर ZFS स्टोर डेटा को कैसे करना है, इसके बारे में बात करने की आवश्यकता है ।

ज़ूल, वीदेव और डिवाइस

इस पूर्ण पूल आरेख में तीन सहायक vdevs, प्रत्येक वर्ग के लिए एक, और RAIDz2 के लिए चार शामिल हैं।

आमतौर पर अनुचित vdev प्रकार और आकारों का एक पूल बनाने का कोई कारण नहीं है - लेकिन यदि आप चाहते हैं, तो कुछ भी आपको ऐसा करने से रोकता है।

ZFS फाइल सिस्टम को वास्तव में समझने के लिए । , आपको इसकी वास्तविक संरचना को ध्यान से देखने की आवश्यकता है। सबसे पहले, ZFS वॉल्यूम प्रबंधन और फ़ाइल सिस्टम के पारंपरिक स्तरों को जोड़ती है। दूसरे, यह लिखते समय एक ट्रांजेक्शनल कॉपी तंत्र का उपयोग करता है। इन विशेषताओं का मतलब है कि सिस्टम संरचनात्मक रूप से सामान्य फ़ाइल सिस्टम और RAID सरणियों से बहुत अलग है। समझने के लिए बुनियादी भवन ब्लॉकों का पहला सेट: एक भंडारण पूल (ज़ूल), एक आभासी डिवाइस (vdev), और एक वास्तविक डिवाइस (डिवाइस)।

zpool

ज़ूलप स्टोरेज पूल सबसे ऊपरी ZFS संरचना है। प्रत्येक पूल में एक या अधिक वर्चुअल डिवाइस होते हैं। बदले में, उनमें से प्रत्येक में एक या अधिक वास्तविक उपकरण (डिवाइस) होते हैं। वर्चुअल पूल स्वायत्त ब्लॉक हैं। एक भौतिक कंप्यूटर में दो या अधिक अलग-अलग पूल हो सकते हैं, लेकिन प्रत्येक अन्य से पूरी तरह से स्वतंत्र है। पूल वर्चुअल डिवाइस साझा नहीं कर सकते।

ZFS की अतिरेक आभासी उपकरणों के स्तर पर है, लेकिन पूल के स्तर पर नहीं। पूल स्तर पर, कोई अतिरेक नहीं है - यदि कोई vdev ड्राइव या विशेष vdev खो जाता है, तो इसके साथ ही पूरा पूल खो जाता है।

आधुनिक भंडारण पूल कैश या वर्चुअल डिवाइस लॉग के नुकसान से बच सकते हैं - हालांकि वे पावर आउटेज या सिस्टम क्रैश के दौरान vdev लॉग खोते हैं तो वे गंदे डेटा की थोड़ी मात्रा खो सकते हैं।

एक आम गलत धारणा है कि ZFS के "डेटा बैंड" (स्ट्रिप्स) पूरे पूल में दर्ज किए जाते हैं। यह सच नहीं है। ज़ूल एक मज़ेदार RAID0 बिल्कुल भी नहीं है, बल्कि यह जटिल जेनेटिक वितरण तंत्र के साथ एक मज़ेदार JBOD है।

अधिकांश भाग के लिए, प्रविष्टियों को उपलब्ध स्थान के अनुसार उपलब्ध आभासी उपकरणों के बीच वितरित किया जाता है, इसलिए सैद्धांतिक रूप से वे सभी एक ही समय में भरे जाएंगे। जेडएफएस के बाद के संस्करणों में, वीदेव के वर्तमान उपयोग (निपटान) को ध्यान में रखा जाता है - यदि एक आभासी डिवाइस दूसरे की तुलना में काफी अधिक लोड होता है (उदाहरण के लिए, रीड लोड के कारण), तो यह उच्चतम मुक्त स्थान गुणांक की उपस्थिति के बावजूद, लेखन के लिए अस्थायी रूप से छोड़ दिया जाएगा।

आधुनिक ZFS रिकॉर्ड वितरण विधियों में निर्मित पुनर्चक्रण का पता लगाने वाला तंत्र विलंबता को कम कर सकता है और असामान्य रूप से उच्च भार की अवधि के दौरान थ्रूपुट को बढ़ा सकता है - लेकिन यह कार्टे ब्लांच नहीं हैएक पूल में अनजाने में धीमे HDDs और तेज़ SSDs का मिश्रण। इस तरह का एक असमान पूल अभी भी सबसे धीमी डिवाइस की गति पर काम करेगा, जैसे कि यह पूरी तरह से ऐसे उपकरणों से बना था।

vdev

प्रत्येक संग्रहण पूल में एक या अधिक वर्चुअल डिवाइस (वर्चुअल डिवाइस, vdev) होते हैं। बदले में, प्रत्येक vdev में एक या अधिक वास्तविक उपकरण शामिल होते हैं। अधिकांश आभासी उपकरणों का उपयोग आसानी से डेटा संग्रहीत करने के लिए किया जाता है, लेकिन CACHE, LOG, और विशेष सहित कई सहायक vdev कक्षाएं हैं। इनमें से प्रत्येक vdev प्रकार में पांच टोपोलॉजी हो सकती हैं: सिंगल-डिवाइस, RAIDz1, RAIDz2, RAIDz3 या दर्पण।

RAIDz1, RAIDz2, और RAIDz3 विशेष रूप से भिन्नताएं हैं जो ओल्ड्स को RAID डबल (विकर्ण) समता कहते हैं। 1, 2, और 3 प्रत्येक डेटा बैंड के लिए कितने समता ब्लॉक आवंटित किए जाते हैं। समानता के लिए अलग डिस्क के बजाय, वर्चुअल RAIDz डिवाइस समान रूप से डिस्क के पार इस समानता को वितरित करते हैं। एक RAIDz सरणी के रूप में कई डिस्क खो सकते हैं क्योंकि इसमें समता ब्लॉक है; यदि वह एक और हारता है, तो वह विफल हो जाएगा और भंडारण पूल को अपने साथ ले जाएगा।

मिरर किए गए वर्चुअल डिवाइस (मिरर vdev) में, प्रत्येक ब्लॉक को vdev में प्रत्येक डिवाइस पर संग्रहीत किया जाता है। यद्यपि सबसे आम दो-विस्तृत दर्पण हैं, दर्पण में किसी भी तरह की मनमानी संख्या हो सकती है - बड़ी प्रतिष्ठानों में, ट्रिपल लोगों को अक्सर पढ़ने के प्रदर्शन और गलती सहिष्णुता को बढ़ाने के लिए उपयोग किया जाता है। Vdev दर्पण किसी भी विफलता से बच सकता है जबकि vdev में कम से कम एक उपकरण काम करना जारी रखता है।

एकल vdevs स्वाभाविक रूप से खतरनाक हैं। ऐसा वर्चुअल डिवाइस एक भी विफलता से नहीं बचेगा - और अगर इसका उपयोग भंडारण या एक विशेष vdev के रूप में किया जाता है, तो इसकी विफलता पूरे पूल को नष्ट कर देगी। यहाँ बहुत सावधान रहें।

CACHE, LOG, और विशेष आभासी उपकरण उपरोक्त टोपोलॉजी में से किसी का उपयोग करके बनाया जा सकता है - लेकिन याद रखें कि एक विशेष आभासी उपकरण खोने का अर्थ है एक पूल खोना, इसलिए अत्यधिक टोपोलॉजी की जोरदार सिफारिश की जाती है।

युक्ति

यह शायद ZFS में समझने का सबसे आसान शब्द है - यह वस्तुतः एक ब्लॉक रैंडम एक्सेस डिवाइस है। याद रखें कि आभासी डिवाइस व्यक्तिगत उपकरणों से बने होते हैं, और पूल आभासी उपकरणों से बना होता है।

डिस्क - चुंबकीय या ठोस राज्य - सबसे आम ब्लॉक डिवाइस हैं जो कि वीदेव बिल्डिंग ब्लॉक्स के रूप में उपयोग किए जाते हैं। हालाँकि, / dev में हैंडल वाला कोई भी उपकरण उपयुक्त है - इसलिए आप पूरे हार्डवेयर RAID सरणियों को अलग-अलग उपकरणों के रूप में उपयोग कर सकते हैं।

एक सरल कच्ची फ़ाइल सबसे महत्वपूर्ण वैकल्पिक ब्लॉक डिवाइसों में से एक है जिसे vdev से बनाया जा सकता है। विरल फ़ाइलों से टेस्ट पूल - पूल कमांड्स की जांच करने का एक बहुत ही सुविधाजनक तरीका है और देखें कि इस टोपोलॉजी के पूल या वर्चुअल डिवाइस में कितनी जगह उपलब्ध है।

आप कुछ ही सेकंड में विरल फ़ाइलों से एक परीक्षण पूल बना सकते हैं - लेकिन बाद में पूरे पूल और इसके घटकों को हटाना न भूलें।

मान लीजिए कि आप आठ डिस्क पर एक सर्वर लगाना चाहते हैं और 10 टीबी डिस्क (~ 9300 GiB) का उपयोग करने की योजना बना रहे हैं - लेकिन आप निश्चित नहीं हैं। टोपोलॉजी आपकी आवश्यकताओं के लिए सबसे उपयुक्त है। उपरोक्त उदाहरण में, सेकंड के एक मामले में हम विरल फाइलों से एक परीक्षण पूल का निर्माण करते हैं - और अब हम जानते हैं कि आठ 10 टीबी ड्राइव से RAIDz2 vdev 50 टीबी उपयोगी क्षमता प्रदान करता है।

उपकरणों का एक अन्य विशेष वर्ग स्पेयर (स्पेयर) है। पारंपरिक उपकरणों के विपरीत हॉट-स्वैपेबल डिवाइस, केवल एक वर्चुअल डिवाइस नहीं, बल्कि पूरे पूल से संबंधित हैं। यदि पूल में कुछ vdev विफल हो जाते हैं, और स्पेयर डिवाइस पूल से जुड़ा हुआ है और उपलब्ध है, तो यह स्वचालित रूप से प्रभावित vdev में शामिल हो जाएगा।

प्रभावित vdev से कनेक्ट होने के बाद, स्पेयर डिवाइस को डेटा की प्रतियां या पुनर्निर्माण मिलना शुरू हो जाता है जो कि लापता डिवाइस पर होना चाहिए। पारंपरिक RAID में, इसे पुनर्निर्माण कहा जाता है, जबकि ZFS में इसे "रेजिलवरिंग" कहा जाता है।

यह ध्यान रखना महत्वपूर्ण है कि प्रतिस्थापन उपकरण स्थायी रूप से विफल उपकरणों को प्रतिस्थापित नहीं करते हैं। यह केवल उस समय को कम करने के लिए एक अस्थायी प्रतिस्थापन है जिसके दौरान vdev गिरावट देखी गई है। व्यवस्थापक द्वारा विफल vdev डिवाइस को प्रतिस्थापित करने के बाद, इस स्थायी डिवाइस पर अतिरेक को बहाल कर दिया जाता है, और SPARE vdev से डिस्कनेक्ट हो जाता है और पूरे पूल के लिए एक स्पेयर के रूप में काम करता है।

डेटासेट, ब्लॉक और सेक्टर

बिल्डिंग ब्लॉक का अगला सेट जिसे आपको ZFS के माध्यम से हमारी यात्रा पर समझने की आवश्यकता है, वह इतना हार्डवेयर नहीं है, लेकिन डेटा को कैसे व्यवस्थित और संग्रहीत किया जाता है। हम यहां कई स्तरों को छोड़ते हैं - जैसे मेटास्लैब - ताकि समग्र संरचना की समझ को बनाए रखते हुए विवरण को ढेर न किया जा सके।

डेटासेट

जब हम पहली बार एक डेटासेट बनाते हैं, तो यह सभी उपलब्ध पूल स्थान को दर्शाता है। फिर हम कोटा निर्धारित करते हैं - और माउंट बिंदु को बदलते हैं। जादू!

Zvol सबसे अधिक भाग के लिए है जो कि एक डेटासेट है, इसकी फाइल सिस्टम लेयर से रहित है, जिसे हम यहां पूरी तरह से सामान्य 4 जी 4

फाइल सिस्टम के साथ बदलते हैं । ZFS डेटासेट एक मानक माउंटेड फाइल सिस्टम के समान है। एक नियमित फ़ाइल सिस्टम की तरह, पहली नज़र में यह "बस एक और फ़ोल्डर" प्रतीत होता है। लेकिन यह भी, पारंपरिक माउंटेड फ़ाइल सिस्टम की तरह, प्रत्येक ZFS डेटासेट का मूल गुणों का अपना सेट होता है।

सबसे पहले, एक डेटासेट में एक नियत कोटा हो सकता है। यदि स्थापित हैzfs set quota=100G poolname/datasetname, तो आप/poolname/datasetname100 से अधिक GiB परमाउंटेड फ़ोल्डर में नहीं लिख सकते।

उपस्थिति की सूचना - और अनुपस्थिति - प्रत्येक पंक्ति की शुरुआत में स्लैश की? प्रत्येक डेटा सेट में ZFS पदानुक्रम और सिस्टम माउंट पदानुक्रम में दोनों का अपना स्थान होता है। ZFS पदानुक्रम में कोई अग्रणी स्लैश नहीं है - आप पूल के नाम से शुरू करते हैं, और फिर एक डेटा सेट से अगले तक का रास्ता। उदाहरण के लिए, एक रचनात्मक नाम के साथ एक पूल में माता-पिता के तहत pool/parent/childनामित डेटासेट के लिए । डिफ़ॉल्ट रूप से, डेटासेट का आरोह बिंदु ZFS पदानुक्रम में इसके नाम के बराबर होगा, शुरुआत में एक स्लैश के साथ - नाम के साथ पूल को माउंट किया गया है , डेटासेट में आरोहित किया गया है , और बच्चे के डाटासेट में मुहिम शुरू की गई है । हालाँकि, डेटासेट के लिए सिस्टम माउंट पॉइंट को बदला जा सकता है। अगर हम संकेत करेंchildparentpool

pool/poolparent/pool/parentchild/pool/parent/child

zfs set mountpoint=/lol pool/parent/child, तो डेटा सेट pool/parent/childसिस्टम में आरोहित है /lol।

डेटासेट के अलावा, हमें वॉल्यूम (zvols) का उल्लेख करना चाहिए। एक वॉल्यूम लगभग डेटा सेट के समान है, सिवाय इसके कि इसमें वास्तव में एक फाइल सिस्टम नहीं है - यह सिर्फ एक ब्लॉक डिवाइस है। उदाहरण के लिए, आप zvolएक नाम के साथ बना सकते हैं, mypool/myzvolफिर इसे ext4 फ़ाइल सिस्टम के साथ प्रारूपित कर सकते हैं, और फिर इस फ़ाइल सिस्टम को माउंट कर सकते हैं - अब आपके पास ext4 फ़ाइल सिस्टम है, लेकिन सभी ZFS सुरक्षा सुविधाओं के लिए समर्थन के साथ! यह एक कंप्यूटर पर मूर्खतापूर्ण लग सकता है, लेकिन यह iSCSI डिवाइस को निर्यात करते समय बैकएंड के रूप में बहुत अधिक मायने रखता है।

ब्लाकों

एक फ़ाइल को एक या अधिक ब्लॉक द्वारा दर्शाया गया है। प्रत्येक ब्लॉक को एक वर्चुअल डिवाइस पर संग्रहीत किया जाता है। ब्लॉक का आकार आमतौर पर रिकॉर्ड किए गए पैरामीटर के बराबर होता है , लेकिन इसे मेटाडेटा या एक छोटी फ़ाइल होने पर 2 ^ राख तक घटाया जा सकता है । यदि आप बहुत छोटी राखियां स्थापित करते हैं

, तो हम वास्तव में बहुत बड़े प्रदर्शन के नुकसान के बारे में मजाक नहीं कर रहे हैं

। जेडएफएस पूल में मेटाडेटा सहित सभी डेटा ब्लॉक में संग्रहीत हैं। प्रत्येक डेटा सेट के लिए अधिकतम ब्लॉक आकार संपत्तिrecordsize(रिकॉर्ड आकार)में परिभाषित किया गया है। रिकॉर्ड का आकार भिन्न हो सकता है, लेकिन यह किसी भी ब्लॉक के आकार या स्थान को नहीं बदलेगा जो पहले से ही डेटासेट को लिखा गया है - यह केवल नए ब्लॉकों के लिए काम करता है जैसा कि वे लिखे गए हैं।

जब तक अन्यथा निर्दिष्ट न हो, वर्तमान रिकॉर्डिंग का आकार डिफ़ॉल्ट रूप से 128 KiB है। यह एक तरह का कठिन समझौता है जिसमें प्रदर्शन आदर्श नहीं होगा, लेकिन ज्यादातर मामलों में भयानक नहीं। Recordsize4K से 1M तक किसी भी मूल्य पर सेट किया जा सकता है (अतिरिक्त सेटिंग्स के साथ recordsizeआप और भी अधिक सेट कर सकते हैं, लेकिन यह शायद ही कभी एक अच्छा विचार है)।

कोई भी ब्लॉक केवल एक फ़ाइल के डेटा को संदर्भित करता है - आप दो अलग-अलग फ़ाइलों को एक ब्लॉक में नहीं निचोड़ सकते। प्रत्येक फ़ाइल में आकार के आधार पर एक या अधिक ब्लॉक होते हैं। यदि फ़ाइल का आकार रिकॉर्ड आकार से छोटा है, तो इसे एक छोटे ब्लॉक में सहेजा जाएगा - उदाहरण के लिए, 2 KiB फ़ाइल वाला ब्लॉक डिस्क पर केवल एक 4 KiB सेक्टर पर कब्जा करेगा।

यदि फ़ाइल काफी बड़ी है और कई ब्लॉक की आवश्यकता है, तो इस फ़ाइल के सभी रिकॉर्ड का आकार होगाrecordsize - पिछले रिकॉर्ड सहित, जिसका मुख्य भाग अप्रयुक्त स्थान हो सकता है ।

ज़वोल वॉल्यूम के पास एक संपत्ति नहीं है recordsize - इसके बजाय उनके पास एक बराबर संपत्ति है volblocksize।

सेक्टर्स

अंतिम, सबसे बुनियादी बिल्डिंग ब्लॉक सेक्टर है। यह सबसे छोटी भौतिक इकाई है जिसे आधार इकाई से लिखा या पढ़ा जा सकता है। कई दशकों तक, अधिकांश डिस्क 512-बाइट क्षेत्रों का उपयोग करते थे। हाल ही में, अधिकांश ड्राइव 4 KiB क्षेत्रों के लिए कॉन्फ़िगर किए गए हैं, और कुछ में - विशेष रूप से SSDs - 8 KiB सेक्टर या इससे भी अधिक।

ZFS के पास एक संपत्ति है जो आपको मैन्युअल रूप से सेक्टर आकार सेट करने की अनुमति देती है। यह एक संपत्ति है ashift। यह कुछ भ्रामक है कि राख दो की शक्ति है। उदाहरण के लिए, इसका ashift=9अर्थ है 2 ^ 9, या 512 बाइट्स का एक सेक्टर आकार।

ZFS प्रत्येक ब्लॉक डिवाइस के बारे में विस्तृत जानकारी के लिए ऑपरेटिंग सिस्टम से पूछता है जब इसे नए vdev में जोड़ा जाता है, और सैद्धांतिक रूप से स्वचालित रूप से इस जानकारी के आधार पर ठीक से राख सेट करता है। दुर्भाग्य से, कई डिस्क विंडोज एक्सपी के साथ संगतता बनाए रखने के लिए अपने सेक्टर आकार के बारे में झूठ बोलते हैं (जो अन्य सेक्टर आकारों के साथ डिस्क को समझने में असमर्थ था)।

इसका मतलब यह है कि ZFS व्यवस्थापक को अपने उपकरणों के वास्तविक क्षेत्र के आकार और मैन्युअल रूप से स्थापित करने के लिए दृढ़ता से सलाह दी जाती हैashift। यदि बहुत छोटा आश्रय सेट किया जाता है, तो खगोलीय रूप से पढ़ने / लिखने के संचालन की संख्या बढ़ जाती है। तो, वास्तविक 4 KiB क्षेत्र में 512-बाइट "सेक्टर" लिखने का मतलब है कि पहले "सेक्टर" लिखना, फिर 4 KiB सेक्टर को पढ़ना, इसे दूसरे 512-बाइट "सेक्टर" के साथ बदलना, इसे नए 4 KiB सेक्टर में वापस लिखना, और इसी तरह प्रत्येक प्रविष्टि के लिए।

वास्तविक दुनिया में, ऐसा जुर्माना सैमसंग ईवीओ ashift=13एसएसडी को मारता है, जिसके लिए उसे कार्य करना चाहिए , लेकिन ये एसएसडी अपने सेक्टर के आकार के बारे में झूठ बोलते हैं, और इसलिए यह डिफ़ॉल्ट रूप से निर्धारित होता है ashift=9। यदि एक अनुभवी सिस्टम प्रशासक इस सेटिंग को नहीं बदलता है, तो यह एसएसडी एक नियमित चुंबकीय एचडीडी की तुलना में धीमा है ।

तुलना के लिए, बहुत बड़े आकार के लिएashiftवस्तुतः कोई दंड नहीं है। उत्पादकता में कोई वास्तविक कमी नहीं है, और अप्रयुक्त स्थान में वृद्धि असीम रूप से छोटी है (या संपीड़न सक्षम के साथ शून्य के बराबर)। इसलिए, हम दृढ़ता से अनुशंसा करते हैं कि यहां तक कि वे ड्राइव जो वास्तव में 512-बाइट सेक्टरों का उपयोग करते हैं ashift=12या ashift=13भविष्य में आत्मविश्वास से देखने के लिए भी स्थापित हो सकते हैं।

संपत्ति ashiftप्रत्येक vdev वर्चुअल डिवाइस के लिए सेट है, और पूल के लिए नहीं , जैसा कि कई गलती से सोचते हैं - और स्थापना के बाद नहीं बदलता है। यदि आपने ashiftपूल में एक नया vdev जोड़ते समय गलती से दस्तक दी है , तो आप इस पूल को कम-प्रदर्शन डिवाइस के साथ अपरिवर्तित रूप से दूषित करते हैं और, एक नियम के रूप में, पूल को नष्ट करने और फिर से शुरू करने के अलावा और कोई रास्ता नहीं है। यहां तक कि vdev को हटाने से आप टूटे हुए सेटअप से नहीं बचेंगेashift!

— ,

, , « » « »,

, — , ,

लिखें (CoW) पर प्रतिलिपि ZFS को इतना भयानक बनाने का मूल आधार है। मूल अवधारणा सरल है - यदि आप फ़ाइल को संशोधित करने के लिए पारंपरिक फ़ाइल सिस्टम से पूछते हैं, तो यह वही करेगा जो आपने अनुरोध किया था। यदि आप फ़ाइल सिस्टम को रिकॉर्डिंग के दौरान कॉपी करने के साथ पूछते हैं, तो यह "अच्छा" कहेगा - लेकिन यह आपके लिए झूठ होगा।

इसके बजाय, कॉपी-राइट फ़ाइल सिस्टम संशोधित ब्लॉक का नया संस्करण लिखता है, और फिर पुराने ब्लॉक के साथ लिंक को तोड़ने और आपके द्वारा लिखे गए नए ब्लॉक को जोड़ने के लिए फ़ाइल मेटाडेटा को अपडेट करता है।

पुरानी इकाई को डिस्कनेक्ट करना और नए को जोड़ना एक ऑपरेशन में किया जाता है, इसलिए इसे बाधित नहीं किया जा सकता है - यदि आप ऐसा होने के बाद बिजली रीसेट करते हैं, तो आपके पास फ़ाइल का एक नया संस्करण है, और यदि आप पहले की शक्ति को रीसेट करते हैं, तो आपके पास पुराना संस्करण है। किसी भी स्थिति में, फ़ाइल सिस्टम में कोई संघर्ष नहीं होगा।

ZFS में लिखते समय नकल न केवल फाइल सिस्टम स्तर पर होती है, बल्कि डिस्क प्रबंधन स्तर पर भी होती है। इसका मतलब यह है कि ZFS रिकॉर्ड में एक जगह ( RAID में एक छेद ) के अधीन नहीं है - एक घटना जब पट्टी केवल आंशिक रूप से रिकॉर्ड करने में कामयाब होती है इससे पहले कि सिस्टम क्रैश हो गया, रिबूट के बाद क्षतिग्रस्त हुई सरणी के साथ। यहाँ पट्टी परमाणु है, vdev हमेशा सुसंगत है, और बॉब आपके चाचा हैं ।

ZIL: ZFS Intent Log

ZFS — , ZIL,

, ZIL, .

SLOG, LOG-, — — , , — vdev, ZIL

ZIL — ZIL SLOG,

लेखन संचालन की दो मुख्य श्रेणियां हैं - सिंक्रोनस (सिंक) और एसिंक्रोनस (एसिंक्रोनस)। अधिकांश वर्कलोड के लिए, लिखित संचालन का अधिकांश भाग अतुल्यकालिक है - फ़ाइल सिस्टम आपको उन्हें एकत्र करने और बैचों में वितरित करने, विखंडन को कम करने और काफी बढ़ती थ्रूपुट की अनुमति देता है।

सिंक्रोनस रिकॉर्डिंग एक पूरी तरह से अलग मामला है। जब कोई एप्लिकेशन एक तुल्यकालिक लिखने का अनुरोध करता है, तो यह फाइल सिस्टम को बताता है: "आपको इसे अभी गैर-वाष्पशील मेमोरी में करने की आवश्यकता है , और तब तक मैं और कुछ नहीं कर सकता।" इसलिए, सिंक्रोनस रिकॉर्डिंग को तुरंत डिस्क के लिए प्रतिबद्ध होना चाहिए - और यदि वह विखंडन बढ़ाता है या बैंडविड्थ को कम करता है, तो ऐसा ही हो।

जेडएफएस नियमित फाइल सिस्टम की तुलना में अलग-अलग समकालिक रिकॉर्डों का इलाज करता है - उन्हें तुरंत नियमित स्टोरेज में अपलोड करने के बजाय, ZFS उन्हें एक विशेष स्टोरेज एरिया में रिकॉर्ड करता है जिसे ZFS आशय लॉग - ZFS इंटेंट लॉग या ZIL कहा जाता है। चाल यह है कि ये रिकॉर्ड भी स्मृति में बने रहते हैं, नियमित रूप से अतुल्यकालिक लिखने के अनुरोधों के साथ एकत्र किया जाता है, बाद में पूरी तरह से सामान्य TXG (लेनदेन समूह, लेनदेन समूह) के रूप में भंडारण में फेंक दिया जाता है।

सामान्य ऑपरेशन में, ZIL रिकॉर्ड किया जाता है और फिर कभी नहीं पढ़ा जाता है। जब, कुछ क्षणों के बाद, ZIL से रिकॉर्डिंग को साधारण TXG में रैम से मुख्य भंडारण में तय किया जाता है, तो उन्हें ZIL से काट दिया जाता है। केवल एक चीज जब ZIL से कुछ पढ़ा जाता है वह है पूल का आयात करना।

यदि ZFS क्रैश होता है - ऑपरेटिंग सिस्टम क्रैश या पावर आउटेज - जब ZIL में डेटा होता है, तो यह डेटा अगले पूल आयात (उदाहरण के लिए, जब आपातकालीन सिस्टम पुनरारंभ होता है) के दौरान पढ़ा जाएगा। ZIL में जो कुछ भी है, वह TXG समूहों में संयुक्त रूप से पढ़ा जाएगा, मुख्य भंडारण के लिए प्रतिबद्ध होगा, और फिर आयात प्रक्रिया के दौरान ZIL से डिस्कनेक्ट कर दिया जाएगा।

वीवीडी हेल्पर वर्गों में से एक को लॉग या एसएलओजी कहा जाता है, माध्यमिक लॉग डिवाइस। उनका एक काम है - पूल को एक अलग और, अधिमानतः, बहुत तेजी से, बहुत अधिक लेखन प्रतिरोध के साथ प्रदान करने के लिए, मुख्य vdev स्टोरेज में ZIL स्टोर करने के बजाय, ZIL स्टोर करने के लिए vdev डिवाइस। ZIL खुद भी स्टोरेज लोकेशन की परवाह किए बिना ऐसा ही व्यवहार करता है, लेकिन अगर LOG के साथ vdev की राइटिंग परफॉर्मेंस बहुत ज्यादा है, तो सिंक्रोनस राइट्स तेज हो जाएंगे।

पूल में लॉग के साथ vdev को जोड़ने से अतुल्यकालिक लेखन प्रदर्शन में सुधार नहीं हो सकता है - भले ही आप सभी को ZIL का उपयोग करने के लिए मजबूर करते हैं zfs set sync=always, फिर भी वे उसी तरह TXG में मुख्य रिपॉजिटरी से बंधे रहेंगे और बिना लॉग के समान गति से। एकमात्र प्रत्यक्ष प्रदर्शन में सुधार सिंक्रोनस रिकॉर्डिंग में देरी है (चूंकि उच्च लॉग गति ऑपरेशन को गति देती है sync)।

हालाँकि, ऐसे वातावरण में जिसे पहले से ही बड़ी संख्या में सिंक्रोनस राइट्स की आवश्यकता होती है, vdev Log अप्रत्यक्ष रूप से एसिंक्रोनस राइट्स और अनकैप्ड रीड्स को गति दे सकता है। एक अलग vdev LOG में ZIL रिकॉर्ड अपलोड करने का मतलब प्राथमिक भंडारण में IOPS के लिए कम प्रतिस्पर्धा है, जो कुछ हद तक सभी पढ़ने और लिखने के संचालन में सुधार करता है।

स्नैपशॉट्स

लिखने की प्रतिलिपि तंत्र भी परमाणु ZFS स्नैपशॉट और वृद्धिशील अतुल्यकालिक प्रतिकृति के लिए एक आवश्यक आधार है। सक्रिय फ़ाइल सिस्टम में एक पॉइंटर ट्री होता है जो वर्तमान डेटा के साथ सभी रिकॉर्ड को चिह्नित करता है - जब आप स्नैपशॉट लेते हैं, तो आप बस इस पॉइंटर ट्री की एक प्रति बनाते हैं।

जब कोई रिकॉर्ड सक्रिय फ़ाइल सिस्टम में ओवरराइट किया जाता है, तो ZFS पहले ब्लॉक के नए संस्करण को अप्रयुक्त स्थान पर लिखता है। यह वर्तमान फ़ाइल सिस्टम से ब्लॉक के पुराने संस्करण का पता लगाता है। लेकिन अगर कुछ स्नैपशॉट पुराने ब्लॉक को संदर्भित करता है, तो यह अभी भी अपरिवर्तित रहता है। पुराने ब्लॉक को वास्तव में तब तक खाली जगह के रूप में बहाल नहीं किया जाएगा जब तक कि इस ब्लॉक के लिंक वाले सभी स्नैपशॉट नष्ट न हो जाएं!

प्रतिकृति

Steam 2015 158 126 927 . rsync — ZFS « » 750% .

40- Windows 7 — . ZFS 289 , rsync — «» 161 , , rsync --inplace.

, rsync . 1,9 — , ZFS 1148 , rsync, rsync --inplace

एक बार जब आप समझ जाते हैं कि स्नैपशॉट कैसे काम करता है, तो प्रतिकृति के सार को समझना आसान है। चूंकि एक स्नैपशॉट रिकॉर्ड करने के लिए पॉइंटर्स का एक पेड़ है, इसलिए यह इस प्रकार है कि अगर हम zfs sendस्नैपशॉट बनाते हैं , तो हम इस पेड़ और इसके साथ जुड़े सभी रिकॉर्ड भेजते हैं। जब हम इस पारित zfs sendमें zfs receiveलक्ष्य वस्तु के लिए, यह ब्लॉक के दोनों वास्तविक सामग्री और संकेत है कि लक्ष्य डेटा सेट करने के लिए ब्लॉक संदर्भ के वृक्ष लिखता है।

दूसरे में सब कुछ और भी दिलचस्प हो जाता है zfs send। अब हमारे पास दो सिस्टम हैं, जिनमें से प्रत्येक में शामिल है poolname/datasetname@1, और आप एक नया स्नैपशॉट शूट करते हैं poolname/datasetname@2। इसलिए, आपके पास स्रोत पूल में datasetname@1और datasetname@2, और लक्ष्य पूल में अब तक केवल पहला स्नैपशॉट है datasetname@1।

चूंकि हमारे पास स्रोत और लक्ष्य के बीच एक सामान्य स्नैपशॉट हैdatasetname@1, हम इसके ऊपर वृद्धिशील कर सकते हैं zfs send। जब हम सिस्टम को बताते हैं zfs send -i poolname/datasetname@1 poolname/datasetname@2, तो यह दो पॉइंटर पेड़ों की तुलना करता है। कोई भी संकेत जो केवल मौजूद हैं @2, जाहिर है, नए ब्लॉकों को संदर्भित करते हैं - इसलिए हमें इन ब्लॉकों की सामग्री की आवश्यकता है।

एक दूरस्थ प्रणाली में, वृद्धिशील प्रसंस्करण sendसरल है। सबसे पहले, हम स्ट्रीम में शामिल सभी नई प्रविष्टियों को रिकॉर्ड करते हैं send, और फिर इन ब्लॉकों में पॉइंटर्स जोड़ते हैं। वोइला, हमारे @2नए सिस्टम में!

ZFS अतुल्यकालिक वृद्धिशील प्रतिकृति rsync जैसे पहले के गैर-स्नैपशॉट तरीकों पर बहुत बड़ा सुधार है। दोनों ही मामलों में, केवल परिवर्तित डेटा प्रसारित किया जाता है - लेकिन rsync को पहले पढ़ना चाहिएडिस्क से सभी डेटा दोनों पक्षों पर राशि की जांच करने और इसकी तुलना करने के लिए। इसके विपरीत, ZFS प्रतिकृति सूचक पेड़ों के अलावा कुछ भी नहीं पढ़ता है - और सामान्य स्नैपशॉट में किसी भी ब्लॉक का प्रतिनिधित्व नहीं किया जाता है।

इनलाइन संपीड़न

कॉपी-ऑन-राइट तंत्र भी अंतर्निहित संपीड़न प्रणाली को सरल करता है। एक पारंपरिक फ़ाइल सिस्टम में, संपीड़न समस्याग्रस्त है - पुराने संस्करण और परिवर्तित डेटा के नए संस्करण दोनों एक ही स्थान पर हैं।

यदि आप एक फ़ाइल के बीच में डेटा के एक टुकड़े पर विचार करते हैं जो कि 0x00000000 से शून्य के मेगाबाइट के रूप में अपना जीवन शुरू करता है और इसी तरह - इसे डिस्क पर एक क्षेत्र में संपीड़ित करना बहुत आसान है। लेकिन क्या होगा अगर हम इस मेगाबाइट को शून्य के मेगाबाइट के साथ जेपीईजी या छद्म यादृच्छिक शोर जैसे मेगाबाइट के साथ बदल दें? अचानक, डेटा के इस मेगाबाइट के लिए एक नहीं, बल्कि 4 KiB के 256 सेक्टरों की आवश्यकता होगी, और डिस्क पर केवल एक सेक्टर आरक्षित होता है।

ZFS को ऐसी कोई समस्या नहीं है, क्योंकि बदले हुए रिकॉर्ड को हमेशा अप्रयुक्त स्थान पर लिखा जाता है - मूल ब्लॉक केवल एक 4 KiB सेक्टर में रहता है, और एक नया रिकॉर्ड 256 का होगा, लेकिन यह कोई समस्या नहीं है - फ़ाइल के "मध्य" से हाल ही में परिवर्तित टुकड़ा अप्रयुक्त स्थान में लिखा जाएगा भले ही इसका आकार बदल गया हो या नहीं, इसलिए ZFS के लिए यह एक सामान्य स्थिति है।

अंतर्निहित ZFS संपीड़न डिफ़ॉल्ट रूप से अक्षम है, और सिस्टम प्लग-इन एल्गोरिदम प्रदान करता है - अब उनमें से LZ4, gzip (1-9), LZJB और ZLE हैं।

LZ4 एक स्ट्रीमिंग एल्गोरिथ्म है जो बहुत तेज़ सीपीयू पर भी - बहुत अधिक उपयोग के मामलों के लिए अत्यंत तेज संपीड़न और विघटन और प्रदर्शन लाभ प्रदान करता है।
GZIP — , Unix-. 1-9, CPU 9. ( ) , c CPU — , .
LZJB — ZFS. , LZ4 .
ZLE - शून्य स्तर एन्कोडिंग, शून्य स्तर एन्कोडिंग। यह सामान्य डेटा को बिल्कुल भी नहीं छूता है, लेकिन शून्य के बड़े अनुक्रमों को संकुचित करता है। यह पूरी तरह से अयोग्य डेटा सेट के लिए उपयोगी है (उदाहरण के लिए, जेपीईजी, एमपी 4, या अन्य पहले से ही संपीड़ित प्रारूप), क्योंकि यह अचूक डेटा को अनदेखा करता है, लेकिन परिणामी रिकॉर्ड में अप्रयुक्त स्थान को संकुचित करता है।

हम लगभग सभी उपयोग मामलों के लिए LZ4 संपीड़न की सलाह देते हैं; अयोग्य डेटा से सामना करने के लिए प्रदर्शन दंड बहुत छोटा है, और विशिष्ट डेटा के लिए प्रदर्शन लाभ महत्वपूर्ण है। इस 2015 की परीक्षा में विंडोज ऑपरेटिंग सिस्टम (हौसले से स्थापित ओएस, अभी तक अंदर कोई डेटा नहीं) के साथ एक आभासी मशीन छवि को कॉपी करना compression=lz427% तेजी से पारित हुआ ।compression=none

एआरसी - अनुकूली प्रतिस्थापन कैश

ZFS एकमात्र आधुनिक फाइल सिस्टम है जो हमारे लिए जाना जाता है जो अपने स्वयं के रीड कैशिंग तंत्र का उपयोग करता है, और रैम में हाल ही में पढ़े गए ब्लॉक की प्रतियां स्टोर करने के लिए ऑपरेटिंग सिस्टम पेज कैश पर निर्भर नहीं करता है।

हालांकि इसका अपना कैश इसकी समस्याओं के बिना नहीं है - ZFS कर्नेल के रूप में तेजी से नए मेमोरी आवंटन अनुरोधों का जवाब नहीं दे सकता है, इसलिए malloc()एआरसी द्वारा कब्जा की गई रैम की आवश्यकता होने पर एक नया मेमोरी आवंटन कॉल विफल हो सकता है। लेकिन अपने स्वयं के कैश का उपयोग करने के अच्छे कारण हैं, कम से कम अभी के लिए।

MacOS, Windows, Linux और BSD सहित सभी प्रसिद्ध आधुनिक ऑपरेटिंग सिस्टम, पेज कैश को लागू करने के लिए LRU एल्गोरिदम (कम से कम हाल ही में प्रयुक्त) का उपयोग करते हैं। यह एक आदिम एल्गोरिथ्म है जो प्रत्येक पढ़ने के बाद कैश्ड ब्लॉक "कतार" को ऊपर उठाता है और नए कैश मिस को जोड़ने के लिए "डाउन कतार" ब्लॉक को ब्लॉक करता है (ब्लॉक जिन्हें डिस्क से पढ़ा जाना चाहिए था, कैश से नहीं)।

आमतौर पर एल्गोरिथ्म ठीक काम करता है, लेकिन बड़े काम करने वाले डेटासेट वाले सिस्टम पर, LRU आसानी से थ्रेशिंग की ओर जाता है - अक्सर ब्लॉक करने के लिए जगह बनाने के लिए बार-बार ब्लॉक करने की ज़रूरत होती है जो फिर से कैश से नहीं पढ़ी जाएगी।

एआरसी - बहुत कम भोली एल्गोरिथ्म, जिसे "भारित" कैश माना जा सकता है। कैश्ड ब्लॉक के प्रत्येक पढ़ने के बाद, यह थोड़ा "भारी" हो जाता है और भीड़ से बाहर निकलना मुश्किल हो जाता है - और भीड़ को हटाने के बाद भी ब्लॉक को एक निश्चित अवधि के लिए ट्रैक किया जाता है । एक खंड जिसे बाहर निचोड़ लिया गया है, लेकिन फिर कैश में वापस पढ़ने की आवश्यकता है, "भारी" हो जाएगा।

इस सब का अंतिम परिणाम बहुत बड़े हिट अनुपात के साथ एक कैश है - कैश में हिट (कैश से पढ़ें) और याद आती है (डिस्क से पढ़ें) के बीच का अनुपात। यह अत्यंत महत्वपूर्ण आँकड़े हैं - न केवल कैश खुद को परिमाण के सेवा आदेशों को तेजी से हिट करता है, कैश मिसेज़ को भी तेजी से परोसा जा सकता है, क्योंकि अधिक कैश हिट, कम समवर्ती डिस्क अनुरोध और उन शेष मिसाइलों के लिए कम देरी जो सेवा की जानी चाहिए। चलाना।

निष्कर्ष

ZFS के मूल शब्दार्थों का अध्ययन करने के बाद - लेखन के दौरान नकल कैसे काम करती है, साथ ही स्टोरेज पूल, वर्चुअल डिवाइस, ब्लॉक, सेक्टर, और फ़ाइलों के बीच संबंध - हम वास्तविक संख्या के साथ वास्तविक प्रदर्शन पर चर्चा करने के लिए तैयार हैं।

अगले भाग में, हम एक दूसरे के साथ तुलना में, साथ ही साथ पारंपरिक लिनक्स कर्नेल RAID टोपोलॉजी के साथ, जिनकी हमने पहले जांच की थी , मिरर किए गए vdev और RAIDz के साथ पूल के वास्तविक प्रदर्शन को देखेंगे ।

सबसे पहले हम केवल मूल बातें पर विचार करना चाहते थे - ZFS खुद को टोपोलोजी - लेकिन बाद इस बारे में हम और अधिक उन्नत ZFS ट्यूनिंग और ट्यूनिंग, इस तरह के L2ARC, स्लॉग और विशेष आवंटन के रूप में सहायक vdev प्रकार के उपयोग सहित बात करने के लिए तैयार हो जाएगा।

ZFS मूल बातें: भंडारण और प्रदर्शन