या वसंत ऋतूमध्ये आम्ही आधीच काही परिचयात्मक विषयांवर चर्चा केली आहे, उदा. तुमच्या ड्राइव्हचा वेग कसा तपासायचा и RAID काय आहे. यापैकी दुसऱ्यामध्ये, आम्ही ZFS मधील विविध मल्टी-डिस्क टोपोलॉजीजच्या कार्यप्रदर्शनाचा अभ्यास सुरू ठेवण्याचे आश्वासन दिले. ही पुढील पिढीची फाइल प्रणाली आहे जी आता सर्वत्र तैनात केली जात आहे सफरचंद ते उबंटू.

बरं, ZFS, जिज्ञासू वाचकांशी परिचित होण्यासाठी आजचा सर्वोत्तम दिवस आहे. फक्त हे जाणून घ्या की OpenZFS डेव्हलपर मॅट अहरेन्सच्या नम्र मूल्यांकनात, "हे खरोखर कठीण आहे."

परंतु आम्ही संख्यांकडे जाण्यापूर्वी - आणि मी वचन देतो - आठ-डिस्क ZFS कॉन्फिगरेशनच्या सर्व प्रकारांसाठी, आम्हाला याबद्दल बोलण्याची आवश्यकता आहे कसे सर्वसाधारणपणे, ZFS डिस्कवर डेटा संग्रहित करते.

Zpool, vdev आणि डिव्हाइस

या पूर्ण पूल आकृतीमध्ये तीन सहाय्यक vdevs समाविष्ट आहेत, प्रत्येक वर्गातील एक आणि RAIDz2 साठी चार

सहसा जुळत नसलेल्या vdev प्रकार आणि आकारांचा पूल तयार करण्याचे कोणतेही कारण नसते - परंतु जर तुम्हाला हवे असेल, तर तुम्हाला असे करण्यापासून रोखणारे काहीही नाही.

ZFS फाइल सिस्टम खरोखर समजून घेण्यासाठी, तुम्हाला त्याची वास्तविक रचना जवळून पाहण्याची आवश्यकता आहे. प्रथम, ZFS पारंपारिक व्हॉल्यूम आणि फाइल सिस्टम व्यवस्थापन स्तर एकत्र करते. दुसरे, ते व्यवहारात्मक कॉपी-ऑन-राईट यंत्रणा वापरते. या वैशिष्ट्यांचा अर्थ असा आहे की प्रणाली परंपरागत फाइल प्रणाली आणि RAID अॅरेपेक्षा संरचनात्मकदृष्ट्या खूप वेगळी आहे. समजण्यासाठी मूलभूत बिल्डिंग ब्लॉक्सचा पहिला संच म्हणजे स्टोरेज पूल (zpool), आभासी उपकरण (vdev), आणि वास्तविक उपकरण (डिव्हाइस).

zpool

zpool स्टोरेज पूल ही सर्वात वरची ZFS रचना आहे. प्रत्येक पूलमध्ये एक किंवा अधिक आभासी उपकरणे असतात. त्या बदल्यात, त्या प्रत्येकामध्ये एक किंवा अधिक वास्तविक उपकरणे (डिव्हाइस) असतात. व्हर्च्युअल पूल हे स्वयंपूर्ण युनिट्स आहेत. एका भौतिक संगणकामध्ये दोन किंवा अधिक स्वतंत्र पूल असू शकतात, परंतु प्रत्येक इतरांपेक्षा पूर्णपणे स्वतंत्र आहे. पूल आभासी उपकरणे सामायिक करू शकत नाहीत.

ZFS रिडंडंसी व्हर्च्युअल डिव्हाइस स्तरावर आहे, पूल स्तरावर नाही. पूल स्तरावर कोणतीही रिडंडंसी नाही-एखादे vdev किंवा समर्पित vdev हरवल्यास, त्याच्यासह संपूर्ण पूल गमावला जातो.

आधुनिक स्टोरेज पूल व्हर्च्युअल डिव्हाइसची कॅशे किंवा लॉग गमावण्यापासून वाचू शकतात - जरी ते पॉवर आउटेज किंवा सिस्टम क्रॅश दरम्यान vdev लॉग गमावल्यास ते थोड्या प्रमाणात गलिच्छ डेटा गमावू शकतात.

एक सामान्य गैरसमज आहे की ZFS "डेटा पट्टे" संपूर्ण पूलमध्ये लिहिलेले आहेत. हे खरे नाही. Zpool हा एक मजेदार RAID0 नाही, तो एक मजेदार आहे जेबीओडी जटिल परिवर्तनीय वितरण यंत्रणेसह.

बर्‍याच भागांसाठी, रेकॉर्ड उपलब्ध व्हर्च्युअल डिव्हाइसेसमध्ये उपलब्ध मोकळ्या जागेनुसार वितरीत केले जातात, म्हणून सिद्धांततः ते सर्व एकाच वेळी भरले जातील. ZFS च्या अधिक अलीकडील आवृत्त्या सध्याचा vdev वापर (विल्हेवाट) विचारात घेतात - जर एक आभासी उपकरण दुसर्‍यापेक्षा लक्षणीयरीत्या व्यस्त असेल (उदाहरणार्थ, रीड लोडमुळे), सर्वात जास्त मोकळ्या जागेचे प्रमाण असूनही ते लेखनासाठी तात्पुरते वगळले जाईल. .

आधुनिक ZFS लेखन वाटप पद्धतींमध्ये तयार केलेली पुनर्वापर शोध यंत्रणा विलंबता कमी करू शकते आणि विलक्षण उच्च भाराच्या काळात थ्रूपुट वाढवू शकते - परंतु तसे होत नाही कार्टे ब्लँचे एका पूलमध्ये मंद HDD आणि जलद SSD चे अनैच्छिक मिश्रण करण्यासाठी. असा असमान पूल अजूनही सर्वात मंद उपकरणाच्या वेगाने कार्य करेल, म्हणजे, जणू ते अशा उपकरणांनी बनलेले आहे.

vdev

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

RAIDz1, RAIDz2 आणि RAIDz3 हे जुने लोक ज्याला दुहेरी (विकर्ण) पॅरिटी RAID म्हणतील त्याचे विशेष प्रकार आहेत. 1, 2 आणि 3 प्रत्येक डेटा लेनला किती पॅरिटी ब्लॉक्स वाटप केले आहेत याचा संदर्भ देतात. पॅरिटी प्रदान करण्यासाठी स्वतंत्र डिस्क्स ठेवण्याऐवजी, व्हर्च्युअल RAIDz साधने संपूर्ण डिस्कवर पॅरिटी अर्ध-समानपणे वितरित करतात. RAIDz अॅरे पॅरिटी ब्लॉक्स असलेल्या डिस्क गमावू शकतो; जर ते दुसरे गमावले तर ते अयशस्वी होईल आणि स्टोरेज पूल सोबत घेऊन जाईल.

मिरर व्हर्च्युअल डिव्हाइसेसमध्ये (मिरर vdev), प्रत्येक ब्लॉक vdev मधील प्रत्येक डिव्हाइसवर संग्रहित केला जातो. जरी दोन-रुंद मिरर सर्वात सामान्य असले तरी, मिररमध्ये कोणत्याही अनियंत्रित डिव्हाइसेसची संख्या असू शकते—मोठ्या इंस्टॉलेशन्समध्ये, वाचन कार्यप्रदर्शन आणि दोष सहिष्णुता सुधारण्यासाठी ट्रिपल्सचा वापर केला जातो. जोपर्यंत vdev मधील किमान एक उपकरण कार्यरत राहते तोपर्यंत vdev मिरर कोणत्याही अपयशापासून वाचू शकतो.

एकल vdevs स्वाभाविकपणे धोकादायक आहेत. असे व्हर्च्युअल डिव्हाइस एका अपयशापासून वाचणार नाही - आणि जर स्टोरेज किंवा विशेष vdev म्हणून वापरला गेला तर त्याच्या अपयशामुळे संपूर्ण पूल नष्ट होईल. येथे खूप सावधगिरी बाळगा.

CACHE, LOG आणि SPECIAL व्हर्च्युअल डिव्हाइस वरीलपैकी कोणत्याही टोपोलॉजीमध्ये तयार केले जाऊ शकतात - परंतु लक्षात ठेवा की एक विशेष आभासी डिव्हाइस गमावणे म्हणजे पूल गमावणे, म्हणून अनावश्यक टोपोलॉजीची अत्यंत शिफारस केली जाते.

डिव्हाइस

ZFS मध्ये समजण्यासाठी ही कदाचित सर्वात सोपी संज्ञा आहे - हे अक्षरशः ब्लॉक रँडम ऍक्सेस डिव्हाइस आहे. लक्षात ठेवा की व्हर्च्युअल उपकरणे वैयक्तिक उपकरणांची बनलेली असतात आणि पूल आभासी उपकरणांचा बनलेला असतो.

डिस्क, एकतर चुंबकीय किंवा घन स्थिती, ही सर्वात सामान्य ब्लॉक उपकरणे आहेत जी vdev चे बिल्डिंग ब्लॉक्स म्हणून वापरली जातात. तथापि, /dev मध्‍ये डिस्क्रिप्टर असलेले कोणतेही डिव्‍हाइस हे करेल - त्यामुळे संपूर्ण हार्डवेअर RAID अॅरे वेगळे डिव्‍हाइस म्‍हणून वापरले जाऊ शकतात.

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

तुम्ही काही सेकंदात विरळ फाइल्समधून चाचणी पूल तयार करू शकता - परंतु नंतर संपूर्ण पूल आणि त्याचे घटक हटवण्यास विसरू नका

समजा तुम्हाला आठ-डिस्क सर्व्हर हवा आहे आणि 10 TB (~9300 GiB) डिस्क्स वापरण्याची योजना आहे - परंतु तुम्हाला खात्री नाही की कोणते टोपोलॉजी तुमच्या गरजेला अनुकूल आहे. वरील उदाहरणात, आम्ही काही सेकंदात विरळ फाइल्समधून एक चाचणी पूल तयार करतो - आणि आता आम्हाला माहित आहे की आठ 2 TB डिस्कचा RAIDz10 vdev वापरण्यायोग्य क्षमता 50 TiB पुरवतो.

उपकरणांचा आणखी एक विशेष वर्ग म्हणजे SPARE. हॉट-स्वॅप डिव्‍हाइसेस, रेग्युलर डिव्‍हाइसेसप्रमाणे, एकाच व्हर्च्युअल डिव्‍हाइसशी संबंधित नसून संपूर्ण पूलशी संबंधित असतात. जर पूलमधील कोणतेही vdev अयशस्वी झाले आणि एखादे स्पेअर डिव्हाइस पूलशी जोडलेले असेल आणि उपलब्ध असेल, तर ते आपोआप प्रभावित vdev मध्ये सामील होईल.

एकदा प्रभावित vdev शी कनेक्ट केल्यानंतर, बदली डिव्हाइस गहाळ डिव्हाइसवर असलेल्या डेटाच्या प्रती किंवा पुनर्रचना प्राप्त करण्यास सुरवात करते. पारंपारिक RAID मध्ये याला "रीबिल्डिंग" असे म्हणतात आणि ZFS मध्ये ते "रिसिल्व्हरिंग" आहे.

हे लक्षात घेणे महत्त्वाचे आहे की बदली उपकरणे अयशस्वी उपकरणे कायमची बदलत नाहीत. vdev ला कमी होण्यासाठी लागणारा वेळ कमी करण्यासाठी ही केवळ तात्पुरती बदली आहे. प्रशासकाने अयशस्वी vdev डिव्हाइस बदलल्यानंतर, रिडंडंसी त्या कायमस्वरूपी डिव्हाइसवर पुनर्संचयित केली जाते, आणि SPARE vdev मधून डिस्कनेक्ट केले जाते आणि संपूर्ण पूलसाठी स्पेअर म्हणून परत येते.

डेटा सेट, ब्लॉक आणि सेक्टर

आमच्या ZFS प्रवासात समजून घेण्यासाठी बिल्डिंग ब्लॉक्सचा पुढील संच हार्डवेअरशी कमी आणि डेटा स्वतः कसा व्यवस्थित आणि संग्रहित केला जातो याच्याशी अधिक संबंधित आहे. एकूण रचना समजून घेताना तपशीलांमध्ये गोंधळ होऊ नये म्हणून आम्ही येथे काही स्तर वगळत आहोत - जसे की मेटास्लॅब.

डेटासेट

जेव्हा आम्ही प्रथम डेटासेट तयार करतो, तेव्हा ते सर्व उपलब्ध पूल स्पेस दाखवते. मग आम्ही कोटा सेट करतो - आणि माउंट पॉइंट बदलतो. जादू!

Zvol हा बहुतेक फक्त त्याच्या फाइलसिस्टम लेयरमधून काढून टाकलेला डेटासेट आहे, जो आम्ही येथे पूर्णपणे सामान्य ext4 फाइल सिस्टमसह बदलतो.

ZFS डेटा संच साधारणपणे मानक आरोहित फाइल प्रणालीसारखाच असतो. नेहमीच्या फाइल सिस्टमप्रमाणे, पहिल्या दृष्टीक्षेपात ते "फक्त दुसरे फोल्डर" असल्याचे दिसते. परंतु नेहमीच्या आरोहित फाइल प्रणालींप्रमाणेच, प्रत्येक ZFS डेटा सेटचे स्वतःचे मूलभूत गुणधर्म असतात.

सर्व प्रथम, डेटासेटमध्ये नियुक्त केलेला कोटा असू शकतो. आपण स्थापित केल्यास zfs set quota=100G poolname/datasetname, नंतर तुम्ही माउंट केलेल्या फोल्डरवर लिहू शकणार नाही /poolname/datasetname 100 GiB पेक्षा जास्त.

प्रत्येक ओळीच्या सुरुवातीला स्लॅशची उपस्थिती-आणि अनुपस्थिती- लक्षात घ्या? ZFS पदानुक्रम आणि सिस्टम माउंट पदानुक्रम या दोन्हीमध्ये प्रत्येक डेटा सेटचे स्वतःचे स्थान असते. ZFS पदानुक्रमात कोणताही अग्रगण्य स्लॅश नाही - तुम्ही पूलच्या नावाने सुरुवात कराल आणि नंतर एका डेटावरून दुसऱ्याकडे जाण्याचा मार्ग. उदाहरणार्थ, pool/parent/child नावाच्या डेटा सेटसाठी child मूळ डेटासेट अंतर्गत parent सर्जनशील नाव असलेल्या तलावामध्ये pool.

डीफॉल्टनुसार, डेटासेटचा माउंट पॉइंट ZFS पदानुक्रमातील त्याच्या नावाच्या समतुल्य असेल, अग्रगण्य स्लॅशसह - नावाचा पूल pool म्हणून आरोहित /pool, डेटा सेट parent मध्ये आरोहित /pool/parent, आणि चाइल्ड डेटा सेट child मध्ये आरोहित /pool/parent/child. तथापि, डेटा सेटचा सिस्टम माउंट पॉइंट बदलला जाऊ शकतो.

आम्ही सूचित केल्यास zfs set mountpoint=/lol pool/parent/child, नंतर डेटा सेट pool/parent/child म्हणून प्रणालीमध्ये आरोहित /lol.

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

ब्लॉक्स

फाइल एक किंवा अधिक ब्लॉक्सद्वारे दर्शविली जाते. प्रत्येक ब्लॉक एका आभासी डिव्हाइसवर संग्रहित केला जातो. ब्लॉक आकार सामान्यतः पॅरामीटरच्या समान असतो रेकॉर्ड आकार, परंतु ते कमी केले जाऊ शकते 2^शिफ्ट, त्यात मेटाडेटा किंवा लहान फाइल असल्यास.

आम्ही खरोखर खरोखर तुम्ही शिफ्ट खूप कमी ठेवल्यास आम्ही प्रचंड कामगिरीच्या दंडाची थट्टा करत नाही आहोत

ZFS पूलमध्ये, मेटाडेटासह सर्व डेटा ब्लॉकमध्ये संग्रहित केला जातो. प्रत्येक डेटा सेटसाठी कमाल ब्लॉक आकार गुणधर्मामध्ये परिभाषित केला आहे recordsize (रेकॉर्ड आकार). रेकॉर्डचा आकार बदलू शकतो, परंतु हे डेटा सेटवर आधीपासून लिहिलेल्या कोणत्याही ब्लॉक्सचा आकार किंवा स्थान बदलणार नाही - हे फक्त नवीन ब्लॉक्सवर जसे ते लिहिल्या जातात त्याप्रमाणे प्रभावित करते.

अन्यथा निर्दिष्ट केल्याशिवाय, वर्तमान डीफॉल्ट एंट्री आकार 128 KiB आहे. हे एक कठीण ट्रेड-ऑफ आहे जेथे कार्यप्रदर्शन परिपूर्ण होणार नाही, परंतु बहुतेक प्रकरणांमध्ये ते भयंकर होणार नाही. Recordsize 4K ते 1M पर्यंत कोणत्याही मूल्यावर सेट केले जाऊ शकते (अतिरिक्त सेटिंग्जसह recordsize आपण आणखी स्थापित करू शकता, परंतु ही क्वचितच चांगली कल्पना आहे).

कोणताही ब्लॉक फक्त एका फाईलचा डेटा संदर्भित करतो - तुम्ही एका ब्लॉकमध्ये दोन भिन्न फाइल्स पिळून काढू शकत नाही. प्रत्येक फाइलमध्ये त्याच्या आकारानुसार एक किंवा अधिक ब्लॉक्स असतात. जर फाइलचा आकार रेकॉर्ड आकारापेक्षा लहान असेल, तर तो लहान ब्लॉकमध्ये संग्रहित केला जाईल - उदाहरणार्थ, 2 KiB फाइल असलेला ब्लॉक डिस्कवर फक्त एक 4 KiB सेक्टर व्यापेल.

जर फाइल इतकी मोठी असेल की अनेक ब्लॉक्सची आवश्यकता असेल, तर त्या फाइलमधील सर्व नोंदी आकाराच्या असतील recordsize - शेवटच्या एंट्रीसह, ज्याचा मुख्य भाग असू शकतो न वापरलेली जागा.

zvol खंडांमध्ये मालमत्ता नाही recordsize - त्याऐवजी त्यांच्याकडे समतुल्य मालमत्ता आहे volblocksize.

सेक्टर्स

शेवटचा, सर्वात मूलभूत बिल्डिंग ब्लॉक सेक्टर आहे. हे सर्वात लहान भौतिक एकक आहे जे होस्ट डिव्हाइसवर लिहिले किंवा वाचले जाऊ शकते. अनेक दशकांपासून, बहुतेक डिस्क्स 512-बाइट सेक्टर्स वापरतात. आजकाल, बहुतेक ड्राइव्ह 4 KiB सेक्टरसाठी कॉन्फिगर केले जातात आणि काही - विशेषत: SSDs - 8 KiB सेक्टर किंवा त्याहूनही मोठ्या साठी कॉन्फिगर केले जातात.

ZFS मध्ये एक वैशिष्ट्य आहे जे तुम्हाला सेक्टर आकार व्यक्तिचलितपणे सेट करण्याची परवानगी देते. ही मालमत्ता ashift. काहीसे गोंधळात टाकणारे, शिफ्ट ही दोन शक्ती आहे. उदाहरणार्थ, ashift=9 म्हणजे सेक्टर आकार 2^9, किंवा 512 बाइट्स.

ZFS ऑपरेटिंग सिस्टीमला प्रत्येक ब्लॉक उपकरणाविषयी तपशीलवार माहिती विचारते जेव्हा ते नवीन vdev मध्ये जोडले जाते, आणि सैद्धांतिकदृष्ट्या स्वयंचलितपणे त्या माहितीच्या आधारावर योग्यरित्या शिफ्ट सेट करते. दुर्दैवाने, Windows XP सह सुसंगतता राखण्यासाठी अनेक ड्राईव्ह त्यांच्या सेक्टर आकाराबद्दल खोटे बोलतात (जे इतर सेक्टर आकारांसह ड्राइव्ह समजण्यास अक्षम होते).

याचा अर्थ असा की ZFS प्रशासकास त्यांच्या डिव्हाइसेसचा वास्तविक सेक्टर आकार माहित असणे आणि व्यक्तिचलितपणे सेट करणे अत्यंत शिफारसीय आहे ashift. शिफ्ट खूप लहान असल्यास, वाचन/लेखन ऑपरेशन्सची संख्या खगोलीयदृष्ट्या वाढते. तर, 512-बाइट "सेक्टर" खऱ्या 4 KiB सेक्टरवर लिहिणे म्हणजे पहिले "सेक्टर" लिहावे लागेल, नंतर 4 KiB सेक्टर वाचा, दुसर्‍या 512-बाइट "सेक्टर" ने ते सुधारा, ते परत नवीनवर लिहा. 4 KiB क्षेत्र, आणि असेच प्रत्येक प्रवेशासाठी.

वास्तविक जगात, असा दंड Samsung EVO SSDs वर परिणाम करतो, ज्यासाठी तो लागू केला पाहिजे ashift=13, परंतु हे एसएसडी त्यांच्या सेक्टर आकाराबद्दल खोटे बोलतात आणि म्हणून डीफॉल्ट वर सेट केले जाते ashift=9. जोपर्यंत अनुभवी सिस्टम प्रशासक हे सेटिंग बदलत नाही तोपर्यंत हे SSD कार्य करते हळू नियमित चुंबकीय HDD.

तुलनेसाठी, खूप मोठे असल्याबद्दल ashift अक्षरशः कोणताही दंड नाही. कोणतेही वास्तविक कार्यप्रदर्शन हिट नाही, आणि न वापरलेल्या जागेतील वाढ असीमित आहे (किंवा कॉम्प्रेशन सक्षम असल्यास शून्य). म्हणून, आम्ही जोरदार शिफारस करतो की 512-बाइट सेक्टर वापरत असलेल्या ड्राइव्हस् देखील स्थापित करा ashift=12 किंवा अगदी ashift=13भविष्याकडे आत्मविश्वासाने पाहण्यासाठी.

मालमत्ता ashift प्रत्येक आभासी उपकरण vdev साठी स्थापित केले आहे, आणि तलावासाठी नाही, बरेच लोक चुकून विचार करतात - आणि स्थापनेनंतर बदलत नाहीत. चुकून मारलं तर ashift जेव्हा तुम्ही पूलमध्ये नवीन vdev जोडता, तेव्हा तुम्ही तो पूल कमी-कार्यक्षमता असलेल्या उपकरणाने अपरिवर्तनीयपणे प्रदूषित केला आहे आणि नियमानुसार, पूल नष्ट करून पुन्हा सुरू करण्याशिवाय दुसरा पर्याय नाही. vdev हटवणे देखील तुटलेल्या सेटिंगपासून तुम्हाला वाचवणार नाही ashift!

कॉपी-ऑन-राइट यंत्रणा

जर एखाद्या नियमित फाइल सिस्टमला डेटा पुन्हा लिहायचा असेल, तर तो जिथे आहे तिथे प्रत्येक ब्लॉक सुधारतो

कॉपी-ऑन-राइट फाइल सिस्टम ब्लॉकची नवीन आवृत्ती लिहिते आणि नंतर जुनी आवृत्ती अनलॉक करते

गोषवारामध्ये, जर आपण ब्लॉक्सच्या वास्तविक भौतिक व्यवस्थेकडे दुर्लक्ष केले तर, आपला "डेटा धूमकेतू" एक "डेटा वर्म" बनतो जो उपलब्ध जागेच्या नकाशावर डावीकडून उजवीकडे सरकतो.

कॉपी-ऑन-राइट स्नॅपशॉट्स कसे कार्य करतात याची आता आम्हाला चांगली कल्पना येऊ शकते - प्रत्येक ब्लॉक एकाधिक स्नॅपशॉट्सचा असू शकतो आणि सर्व संबंधित स्नॅपशॉट्स नष्ट होईपर्यंत टिकून राहतील.

कॉपी ऑन राइट (CoW) यंत्रणा हा ZFS ला इतकी अप्रतिम प्रणाली बनवण्याचा मूलभूत आधार आहे. मूळ संकल्पना सोपी आहे - जर तुम्ही पारंपारिक फाइल सिस्टमला फाइल बदलण्यास सांगितले, तर ती तुम्ही जे विचारले तेच करेल. तुम्ही कॉपी-ऑन-राईट फाइल सिस्टीमला तेच करायला सांगितल्यास, ते “ठीक आहे” असे म्हणेल—परंतु ते तुमच्याशी खोटे बोलेल.

त्याऐवजी, कॉपी-ऑन-राइट फाइल सिस्टम सुधारित ब्लॉकची नवीन आवृत्ती लिहिते, आणि नंतर जुन्या ब्लॉकला अनलिंक करण्यासाठी आणि तुम्ही नुकत्याच लिहिलेल्या नवीन ब्लॉकशी संबद्ध करण्यासाठी फाइलचा मेटाडेटा अपडेट करते.

जुना ब्लॉक अनलिंक करणे आणि नवीन लिंक करणे एका ऑपरेशनमध्ये केले जाते, त्यामुळे त्यात व्यत्यय येऊ शकत नाही - जर तुम्ही असे झाल्यानंतर पॉवर रीसेट केला, तर तुमच्याकडे फाईलची नवीन आवृत्ती असेल आणि जर तुम्ही आधी पॉवर रीसेट केली असेल तर तुमच्याकडे आहे. जुनी आवृत्ती. कोणत्याही परिस्थितीत, फाइल सिस्टममध्ये कोणताही संघर्ष होणार नाही.

ZFS मध्ये कॉपी-ऑन-राईट केवळ फाइल सिस्टम स्तरावरच नाही तर डिस्क व्यवस्थापन स्तरावर देखील होते. याचा अर्थ ZFS रेकॉर्डमधील व्हाईटस्पेससाठी अतिसंवेदनशील नाही (RAID मध्ये छिद्र) - रीबूट केल्यानंतर अ‍ॅरेला झालेल्या नुकसानासह, सिस्टीम क्रॅश होण्यापूर्वी स्ट्रिपची केवळ अंशतः रेकॉर्ड केलेली घटना. येथे स्ट्राइप अणू लिहीली आहे, vdev नेहमी अनुक्रमिक आहे, आणि बॉब तुझा काका आहे.

ZIL: ZFS हेतू लॉग

ZFS समकालिक लेखन एका विशेष पद्धतीने हाताळते - ते त्यांना तात्पुरते संग्रहित करते परंतु ZIL मध्ये नंतर कायमस्वरूपी असिंक्रोनस लेखनासह लिहिण्यापूर्वी.

सामान्यतः, ZIL ला लिहिलेला डेटा पुन्हा कधीही वाचला जात नाही. परंतु सिस्टम अयशस्वी झाल्यानंतर हे शक्य आहे

SLOG, किंवा दुय्यम LOG डिव्हाइस हे फक्त एक विशेष आहे - आणि शक्यतो खूप वेगवान - vdev जेथे ZIL मुख्य स्टोरेजपासून वेगळे संग्रहित केले जाऊ शकते.

क्रॅश झाल्यानंतर, ZIL मधील सर्व गलिच्छ डेटा पुन्हा प्ले केला जातो - या प्रकरणात, ZIL SLOG वर आहे, त्यामुळे ते तिथेच पुन्हा प्ले केले जाते

लेखनाच्या दोन मुख्य श्रेणी आहेत: सिंक्रोनस (सिंक्रोनस) आणि एसिंक्रोनस (असिंक). बर्‍याच वर्कलोड्ससाठी, बहुसंख्य लेखन अतुल्यकालिक असतात — फाइल सिस्टम त्यांना एकत्रित आणि बॅचमध्ये जारी करण्याची परवानगी देते, विखंडन कमी करते आणि थ्रूपुटमध्ये लक्षणीय वाढ करते.

सिंक्रोनस रेकॉर्डिंग ही पूर्णपणे वेगळी बाब आहे. जेव्हा एखादा ऍप्लिकेशन सिंक्रोनस राईटची विनंती करतो, तेव्हा ते फाइल सिस्टमला सांगते: "तुम्हाला हे नॉन-व्होलॅटाइल मेमरीवर कमिट करणे आवश्यक आहे. ताबडतोब, आणि तोपर्यंत मी आणखी काही करू शकत नाही.” म्हणून, सिंक्रोनस राइट्स ताबडतोब डिस्कसाठी वचनबद्ध असणे आवश्यक आहे - आणि जर यामुळे विखंडन वाढले किंवा थ्रुपुट कमी झाले, तर तसे व्हा.

ZFS सिंक्रोनस राइट्स नियमित फाइल सिस्टीमपेक्षा वेगळ्या पद्धतीने हाताळते — त्यांना ताबडतोब नियमित स्टोरेजमध्ये फ्लश करण्याऐवजी, ZFS त्यांना ZFS इंटेंट लॉग, किंवा ZIL नावाच्या विशेष स्टोरेज क्षेत्रामध्ये कमिट करते. युक्ती म्हणजे या नोंदी देखील मेमरीमध्ये राहा, सामान्य असिंक्रोनस लेखन विनंत्यांसह एकत्रित केले जाईल, नंतर पूर्णपणे सामान्य TXGs (व्यवहार गट) म्हणून स्टोरेजमध्ये फ्लश केले जाईल.

सामान्य ऑपरेशन दरम्यान, ZIL लिहिले जाते आणि पुन्हा कधीही वाचले जात नाही. जेव्हा, काही क्षणांनंतर, ZIL कडील रेकॉर्ड RAM मधील नियमित TXG मध्ये मुख्य स्टोरेजसाठी वचनबद्ध असतात, तेव्हा ते ZIL पासून वेगळे केले जातात. पूल आयात करताना केवळ ZIL कडून काहीतरी वाचले जाते.

ZIL मध्ये डेटा असताना ZFS अयशस्वी झाल्यास — ऑपरेटिंग सिस्टम क्रॅश किंवा पॉवर आउटेज — तो डेटा पुढील पूल आयात दरम्यान वाचला जाईल (उदाहरणार्थ, फेलओव्हर सिस्टम रीस्टार्ट झाल्यावर). ZIL मध्ये जे काही आहे ते वाचले जाईल, TXG मध्ये गटबद्ध केले जाईल, मुख्य स्टोअरला वचनबद्ध केले जाईल आणि नंतर आयात प्रक्रियेदरम्यान ZIL पासून वेगळे केले जाईल.

vdev सहाय्यक वर्गांपैकी एकास LOG किंवा SLOG म्हणतात, एक दुय्यम LOG उपकरण. त्याचे एक कार्य आहे - ZIL संचयित करण्यासाठी मुख्य vdev स्टोरेजवर ZIL संचयित करण्याऐवजी, एक वेगळा आणि शक्यतो, अधिक जलद, खूप उच्च लेखन प्रतिरोध, vdev डिव्हाइससह पूल प्रदान करणे. स्टोरेज स्थानाकडे दुर्लक्ष करून ZIL स्वतः सारखेच वागते, परंतु जर LOG सह vdev मध्ये खूप उच्च लेखन कार्यप्रदर्शन असेल, तर सिंक्रोनस लेखन जलद होईल.

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

तथापि, अशा वातावरणात ज्याला आधीच पुष्कळ समकालिक लेखन आवश्यक आहे, vdev LOG अप्रत्यक्षपणे असिंक्रोनस लेखन आणि अनकॅशेड रीड्सची गती वाढवू शकते. ZIL रेकॉर्ड वेगळ्या vdev LOG वर ऑफलोड करणे म्हणजे प्राथमिक स्टोरेजवर IOPS साठी कमी विवाद, जे काही प्रमाणात सर्व वाचन आणि लेखनाचे कार्यप्रदर्शन सुधारते.

स्नॅपशॉट्स

ZFS अणु स्नॅपशॉट्स आणि वाढीव असिंक्रोनस प्रतिकृतीसाठी कॉपी-ऑन-राईट यंत्रणा देखील आवश्यक पाया आहे. सक्रिय फाइल सिस्टममध्ये एक पॉइंटर ट्री आहे जो वर्तमान डेटासह सर्व नोंदी चिन्हांकित करतो - जेव्हा तुम्ही स्नॅपशॉट घेता तेव्हा तुम्ही फक्त या पॉइंटर ट्रीची एक प्रत बनवता.

सक्रिय फाइल प्रणालीवर रेकॉर्ड ओव्हरराईट केल्यावर, ZFS प्रथम ब्लॉकची नवीन आवृत्ती न वापरलेल्या जागेवर लिहिते. नंतर सध्याच्या फाइल सिस्टममधून ब्लॉकची जुनी आवृत्ती काढून टाकते. परंतु काही स्नॅपशॉटमध्ये जुन्या ब्लॉकचा संदर्भ असल्यास, तो अजूनही अपरिवर्तित राहतो. जोपर्यंत त्या ब्लॉकचा संदर्भ देणारे सर्व स्नॅपशॉट नष्ट होत नाहीत तोपर्यंत जुना ब्लॉक मोकळी जागा म्हणून रिस्टोअर केला जाणार नाही!

प्रतिकृती

2015 मध्ये माझी स्टीम लायब्ररी 158 GiB होती आणि त्यात 126 फाइल्स समाविष्ट होत्या. हे rsync साठी इष्टतम परिस्थितीच्या अगदी जवळ आहे - नेटवर्कवर ZFS प्रतिकृती "केवळ" 927% जलद होती.

त्याच नेटवर्कवर, एकाच 40GB Windows 7 व्हर्च्युअल मशीन इमेज फाइलची प्रतिकृती बनवणे ही पूर्णपणे वेगळी गोष्ट आहे. ZFS प्रतिकृती rsync पेक्षा 289 पट वेगवान आहे—किंवा "केवळ" 161 पट जलद आहे जर तुम्ही --inplace स्विचसह rsync ला कॉल करण्यासाठी पुरेसे जाणकार असाल.

जेव्हा VM प्रतिमा स्केल करते, तेव्हा rsync त्याच्यासह स्केल जारी करते. आधुनिक VM प्रतिमेसाठी 1,9 TiB आकार इतका मोठा नाही—परंतु तो इतका मोठा आहे की ZFS प्रतिकृती rsync पेक्षा 1148 पट वेगवान आहे, अगदी 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 पासून शून्याच्या मेगाबाइटच्या रूपात त्याचे आयुष्य सुरू करणार्‍या फाईलच्या मध्यभागी डेटाचा तुकडा विचारात घेतल्यास - डिस्कवरील एका सेक्टरमध्ये संकुचित करणे खूप सोपे आहे. पण जर आपण शून्याच्या या मेगाबाइटच्या जागी जेपीईजी किंवा स्यूडो-रँडम नॉइज सारख्या मेगाबाइटच्या असंक्रमित डेटाने बदलले तर काय होईल? अचानक, त्या मेगाबाइट डेटासाठी एक नव्हे तर 256 4 KiB सेक्टर्स आवश्यक असतील आणि त्या डिस्क स्पेसमध्ये फक्त एक सेक्टर राखीव होता.

ZFS ला ही समस्या नाही, कारण सुधारित नोंदी नेहमी न वापरलेल्या जागेवर लिहिल्या जातात - मूळ ब्लॉक फक्त एक 4 KiB सेक्टर घेते, आणि नवीन लेखन 256 घेईल, परंतु ही समस्या नाही - एक अलीकडे सुधारित खंड फाईलचा "मध्यम" आकार बदलला आहे की नाही याची पर्वा न करता न वापरलेल्या जागेवर लिहिला जाईल, त्यामुळे ZFS साठी ही पूर्णपणे सामान्य परिस्थिती आहे.

बिल्ट-इन ZFS कॉम्प्रेशन डीफॉल्टनुसार अक्षम केले आहे, आणि सिस्टम प्लग करण्यायोग्य अल्गोरिदम ऑफर करते - सध्या LZ4, gzip (1-9), LZJB आणि ZLE सह.

• LZ4 हे एक स्ट्रीमिंग अल्गोरिदम आहे जे अत्यंत वेगवान कॉम्प्रेशन आणि डीकंप्रेशन आणि बर्‍याच वापराच्या प्रकरणांसाठी कार्यप्रदर्शन लाभ देते - अगदी अगदी हळू CPU वर देखील.
• जीझेआयपीपी एक आदरणीय अल्गोरिदम आहे जो सर्व युनिक्स वापरकर्त्यांना माहित आहे आणि आवडतो. 1-9 पातळीसह, कॉम्प्रेशन लेव्हल 9-XNUMX सह अंमलात आणले जाऊ शकते, जसजसे तुम्ही XNUMX ची पातळी गाठता तेव्हा वाढत्या कॉम्प्रेशन रेशोसह आणि CPU वापरासह. अल्गोरिदम सर्व मजकूर (किंवा इतर अत्यंत संकुचित करण्यायोग्य) वापर प्रकरणांसाठी योग्य आहे, परंतु बर्‍याचदा CPU समस्या निर्माण करतात अन्यथा - वापरा सावधगिरीने, विशेषतः उच्च स्तरांवर.
• LZJB - ZFS मध्ये मूळ अल्गोरिदम. हे अप्रचलित आहे आणि यापुढे वापरले जाऊ नये, LZ4 प्रत्येक प्रकारे श्रेष्ठ आहे.
• वाईटरित्या - शून्य पातळी एन्कोडिंग, शून्य पातळी एन्कोडिंग. हे सामान्य डेटाला अजिबात स्पर्श करत नाही, परंतु ते शून्यांच्या मोठ्या अनुक्रमांना संकुचित करते. संकुचित न करता येणार्‍या डेटाकडे दुर्लक्ष केल्यामुळे (जसे की JPEG, MP4 किंवा इतर आधीच संकुचित स्वरूप) पूर्णत: संकुचित न करता येणार्‍या डेटा सेटसाठी उपयुक्त आहे परंतु परिणामी रेकॉर्डमध्ये न वापरलेली जागा संकुचित करते.

आम्ही जवळजवळ सर्व वापर प्रकरणांसाठी LZ4 कॉम्प्रेशनची शिफारस करतो; संकुचित न करता येणार्‍या डेटाशी व्यवहार करताना कार्यप्रदर्शन दंड खूप लहान आहे, आणि वाढ ठराविक डेटासाठी कामगिरी लक्षणीय आहे. विंडोज ऑपरेटिंग सिस्टमच्या नवीन इन्स्टॉलेशनसाठी व्हर्च्युअल मशीन इमेज कॉपी करणे (नवीन स्थापित ओएस, अद्याप आत कोणताही डेटा नाही) compression=lz4 पेक्षा 27% वेगाने उत्तीर्ण झाले compression=none, मध्ये 2015 पासून ही चाचणी.

ARC - अडॅप्टिव्ह रिप्लेसमेंट कॅशे

ZFS ही आपल्याला माहित असलेली एकमेव आधुनिक फाइल प्रणाली आहे जी RAM मध्ये अलीकडे वाचलेल्या ब्लॉक्सच्या प्रती संग्रहित करण्यासाठी ऑपरेटिंग सिस्टमच्या पृष्ठ कॅशेवर अवलंबून न राहता स्वतःची वाचन कॅशिंग यंत्रणा वापरते.

जरी नेटिव्ह कॅशे त्याच्या समस्यांशिवाय नसली तरी - ZFS नवीन मेमरी वाटप विनंत्यांना कर्नलप्रमाणे त्वरित प्रतिसाद देऊ शकत नाही, म्हणून नवीन कॉल malloc() सध्या ARC द्वारे व्यापलेली RAM आवश्यक असल्यास मेमरी वाटप अयशस्वी होऊ शकते. परंतु तुमची स्वतःची कॅशे वापरण्याची चांगली कारणे आहेत, किमान आतासाठी.

मॅकओएस, विंडोज, लिनक्स आणि बीएसडीसह सर्व ज्ञात आधुनिक ऑपरेटिंग सिस्टीम, पेज कॅशे लागू करण्यासाठी LRU (कमीतकमी अलीकडे वापरलेले) अल्गोरिदम वापरतात. हा एक आदिम अल्गोरिदम आहे जो प्रत्येक वाचनानंतर कॅशे केलेला ब्लॉक "रांगेच्या शीर्षस्थानी" ढकलतो आणि नवीन कॅशे मिस्स जोडण्यासाठी आवश्यकतेनुसार ब्लॉक "रांगेच्या तळाशी" ढकलतो (ब्लॉक्स जे डिस्कवरून वाचले गेले असावेत. कॅशेपासून) वरपर्यंत.

सहसा अल्गोरिदम चांगले कार्य करते, परंतु मोठ्या कार्यरत डेटा सेट असलेल्या सिस्टमवर, LRU सहजपणे थ्रॅशिंगला कारणीभूत ठरते—कॅशेमधून पुन्हा कधीही वाचले जाणार नाही अशा ब्लॉक्ससाठी जागा तयार करण्यासाठी वारंवार आवश्यक ब्लॉक्स बाहेर काढणे.

कंस खूप कमी भोळे अल्गोरिदम आहे ज्याला "भारित" कॅशे मानले जाऊ शकते. प्रत्येक वेळी कॅशे केलेला ब्लॉक वाचला जातो, तो बाहेर काढणे थोडे जड आणि कठीण होते - आणि ब्लॉक बाहेर काढल्यानंतरही ट्रॅक केले ठराविक कालावधीत. एक ब्लॉक जो बाहेर काढला गेला आहे परंतु नंतर कॅशेमध्ये परत वाचण्याची आवश्यकता आहे तो देखील जड होईल.

या सर्वांचा अंतिम परिणाम म्हणजे खूप जास्त हिट गुणोत्तर असलेले कॅशे-कॅशे हिट्स (कॅशेमधून वाचले जाते) आणि मिस्स (डिस्कमधून वाचलेले) यांच्यातील गुणोत्तर. ही एक अत्यंत महत्त्वाची आकडेवारी आहे - केवळ कॅशे हिट्सनेच मॅग्निट्यूडच्या ऑर्डरची सर्व्हिसिंग केली जात नाही, कॅशे मिस्स देखील जलद सर्व्हिस केल्या जाऊ शकतात, कारण कॅशे हिट्स जितक्या जास्त असतील, डिस्कवर कमी समवर्ती विनंत्या आणि उरलेल्या मिस्ससाठी विलंब कमी असेल. ते डिस्कसह सर्व्हिस केलेले असणे आवश्यक आहे.

निष्कर्ष

आता आम्ही ZFS चे मूलभूत शब्दार्थ कव्हर केले आहे—कॉपी-ऑन-राइट कसे कार्य करते, तसेच स्टोरेज पूल, व्हर्च्युअल डिव्हाइसेस, ब्लॉक्स, सेक्टर्स आणि फाइल्समधील संबंध—आम्ही वास्तविक-जगातील कामगिरीवर चर्चा करण्यास तयार आहोत वास्तविक संख्या.

पुढील भागात, आम्ही मिरर केलेले vdev आणि RAIDz पूल्सचे प्रत्यक्ष कार्यप्रदर्शन, एकमेकांच्या तुलनेत आणि आम्ही तपासलेल्या पारंपारिक लिनक्स कर्नल RAID टोपोलॉजीशी तुलना करू. पूर्वी.

सुरुवातीला आम्हाला फक्त मूलभूत गोष्टी - ZFS टोपोलॉजीज - पण नंतर कव्हर करायचे होते अशा आम्ही ZFS च्या अधिक प्रगत कॉन्फिगरेशन आणि ट्यूनिंगबद्दल बोलण्यास तयार आहोत, ज्यात L2ARC, SLOG आणि विशेष वाटप सारख्या सहाय्यक vdev प्रकारांचा वापर समाविष्ट आहे.

स्त्रोत: www.habr.com