ZFS का पंथ

IT circles में एक प्रकार की cult-like या “fanboy” मानसिकता विकसित होना काफी common है। यह प्रतिक्रिया technologies और products के प्रति क्यों होती है यह मुझे पूरी तरह समझ नहीं आता, लेकिन यह होती है यह निर्विवाद है। एक क्षेत्र जहाँ मैंने कभी नहीं सोचा था कि यह होगा वह filesystems का क्षेत्र है – “under the hood” system components में से एक जो, हाल ही तक, literally कोई ध्यान नहीं पाता था यहाँ तक कि decently technical circles में भी। सच कहें तो, Active Directory बनाम NTFS से कुछ कब आता है यह गलत समझना लगभग ubiquitous है। Filesystems को, बिल्कुल सीधे शब्दों में, ignore किया जाता है। Windows NT 4 के release और NTFS के एकमात्र viable option होने के बाद से यह विचार कि एक filesystem एक operating system का एक intrinsic component नहीं है और file storage के लिए अन्य options हो सकते हैं, लगभग fade away हो गया है। वह है, हाल ही तक।

एक community जहाँ, कुछ हद तक, यह नहीं हुआ था वह Linux community थी, लेकिन वहाँ भी Ext2 और इसके descendants ने इतनी completely mindshare जीत ली कि भले ही वे widely available थे, alternative filesystems को sidelines कर दिया गया और historically केवल XFS को कोई ध्यान मिला, और यहाँ तक कि उसे भी बहुत कम मिला।

जहाँ कुछ truly strange behavior हुई है, अधिक recently, वह Oracle के ZFS filesystem के आसपास है, जो मूल रूप से Solaris operating system और X4500 “Thumper” open storage platform (मूल रूप से Oracle acquisition से पहले Sun के तहत) के लिए developed किया गया था। उस समय (नौ साल पहले) जब ZFS released हुआ, competing filesystems अधिकांशतः उन large disk arrays को handle करने के लिए ill prepared थे जो आने वाले वर्षों में बनने की उम्मीद थी। ZFS उन्हें handle करने के लिए designed किया गया था और large scale filesystems के युग का herald बना। उस समय अधिकांश filesystems की तरह, ZFS एक single operating system तक ही limited था और इसलिए, जबकि filesystem design में एक great leap forward के रूप में widely regarded किया गया, storage world में बहुत कम ripples पैदा हुईं और “systems” world में और भी कम जहाँ यहाँ तक कि Solaris administrators ने आम तौर पर इसे काफी लंबे समय तक केवल interest का एक point माना, ज़्यादातर उस tried और true UFS पर stick रहना choose किया जिसे वे वर्षों से उपयोग कर रहे थे।

ZFS वास्तव में, एक groundbreaking filesystem था और मैं था, और रहता हूँ, इसका एक great proponent। लेकिन यह समझना बहुत महत्वपूर्ण है कि ZFS ने क्या किया, इसके goals क्या हैं, वे goals क्यों महत्वपूर्ण थे और यह आज हम पर कैसे apply होता है। ZFS की complexity ने filesystem कैसे काम करता है और कब इसका उपयोग करना appropriate है इसके बारे में बहुत confusion और misunderstanding पैदा की है।

ZFS के principal goals थे एक ऐसा filesystem बनाना जो बहुत large disk arrays तक well scale करने में capable हो। इसके introduction के समय, जिस scale तक ZFS capable था वह अन्य file systems में unheard of था लेकिन real world में किसी filesystem के इतने large grow होने की कोई जरूरत नहीं थी। जब तक जरूरत उत्पन्न हुई, कई अन्य file systems जैसे NTFS, XFS, Ext3 और अन्य ने need को accommodate करने के लिए scale किया था। ZFS ने निश्चित रूप से larger filesystem handling की charge lead की लेकिन उसके तुरंत बाद कई अन्य ने भी join किया।

क्योंकि ZFS Solaris world में originated हुआ जहाँ, सभी big iron UNIX systems की तरह, कोई hardware RAID नहीं है, software RAID का उपयोग करना पड़ता था। Solaris में हमेशा से software RAID अपने own subsystem के रूप में available था। एक new software RAID implementation को directly ZFS में build करने का निर्णय लिया गया। यह RAID layer और filesystem दोनों के लिए एक single tool set के माध्यम से simplified management की अनुमति देता। इसने ZFS में कोई significant change या advantage introduce नहीं किया, जैसा कि अक्सर माना जाता है, इसने बस software RAID layer के interface को अपने command set से ZFS command set का हिस्सा बनाने के लिए shift किया।

ZFS की RAID implementation ने parity RAID levels में variable width stripes introduce की। इस innovation ने “write hole” के नाम से जाने जाने वाले एक minor parity RAID risk को close किया। यह innovation बहुत nice थी लेकिन काफी late आई क्योंकि reliable parity RAID का युग समाप्त होना शुरू हो रहा था और write hole problem को already battery backed array caches के उपयोग के माध्यम से और उसी समय के आसपास, non-volatile array caches के माध्यम से – power loss से बचें और write hole से बचें – parity arrays का एक unmentioned “background noise” risk माना जाता था। ZFS को इस issue को address करना था क्योंकि, software RAID के रूप में, यह hardware RAID की तुलना में write hole के प्रति अधिक जोखिम में था क्योंकि power loss के विरुद्ध protected cache के लिए कोई opportunity नहीं है – hardware RAID arrays के लिए power protection की एक additional layer की potential प्रदान करता है।

ZFS का real “innovation” जो अनजाने में हुआ वह यह था कि केवल 1, 5, 6 और 10 के usual RAID levels implement करने के बजाय उन्होंने इन levels को अपने naming conventions के साथ “brand” किया। RAID 5 को RAIDZ कहा जाता है। RAID 6 को RAIDZ2 कहा जाता है। RAID 1 को बस mirroring कहा जाता है। और इसी तरह। इसे उस समय widely silly और pointlessly confusing माना गया था लेकिन, जैसा कि निकला, वह confusion कई साल बाद ZFS के revival का cornerstone बन गई।

यह note करना जरूरी है कि ZFS ने बाद में एक RAID 7 (aka RAID 7.3) triple parity RAID system का industry का पहला production implementation जोड़ा और इसे RAIDZ3 brand किया। यह later addition large scale arrays के लिए एक important innovation है जिन्हें capacity में उत्कृष्ट होने की जरूरत है जबकि अत्यंत safe रहते हुए लेकिन performance को sacrifice करने के लिए तैयार हैं। यह ZFS की एक unique feature बनी हुई है लेकिन एक जो rarely उपयोग की जाती है।

Storage stack को collapse करने और storage के सभी aspects को manage करने के लिए एक single command set उपयोग करने की spirit में logical volume management functions को भी ZFS में rolled किया गया। यह कुछ circles में गलती से माना जाता है कि ZFS ने logical volume management introduce किया लेकिन लगभग सभी enterprise platforms, जिनमें AIX, Linux, Windows और यहाँ तक कि Solaris खुद भी शामिल हैं, के पास पहले से ही वर्षों से logical volume management था। ZFS यह एक नया paradigm introduce करने के लिए नहीं कर रहा था बल्कि management consolidate करने और तीनों key storage layers (RAID, logical volume management और filesystem) को एक single entity में wrap करने के लिए कर रहा था जो manage करना easier होगी और stack पर ऊपर और नीचे inherent communications provide कर सकती थी। इस method के pros और cons हैं और एक industry opinion लगभग एक decade बाद भी unformed रहती है।

तीन systems को एक में consolidate करने का एक सबसे महत्वपूर्ण aspect यह है कि अब हमारे पास discuss करने के लिए एक बहुत confusing product है। ZFS एक filesystem है, हाँ, लेकिन केवल एक filesystem नहीं। यह एक logical volume manager है, लेकिन केवल एक logical volume manager नहीं। लोग ZFS को filesystem के रूप में refer करते हैं, जो इसका primary function है, लेकिन यह कि यह filesystem से बहुत अधिक है बहुत confusing हो सकता है और अन्य storage systems के विरुद्ध comparisons मुश्किल बनाता है। उस समय मुझे विश्वास है कि इस confusion की आशा नहीं थी।

इस confusing merger से जो result हुआ है वह यह है कि ZFS को अक्सर अन्य filesystems के साथ compare किया जाता है, जैसे XFS या Ext4। लेकिन यह confusing है क्योंकि ZFS एक complete stack है और XFS केवल एक stack का एक aspect है। ZFS को XFS alone की तुलना में MD (Linux Software RAID) / LVM / XFS या SmartArray (HP Hardware RAID) / LVM/ XFS से बेहतर compare किया जाएगा। अन्यथा यह appears होता है कि ZFS में ऐसी features हैं जो XFS में नहीं हैं लेकिन, reality में, यह केवल एक semantic victory है। ZFS advocates द्वारा अक्सर touted की जाने वाली अधिकांश features ZFS के साथ नहीं आई थीं और ZFS के exist होने से बहुत पहले alternative filesystems के साथ commonly available थीं। लेकिन “क्या आपका filesystem वह करता है” compare करना मुश्किल है क्योंकि answer है “नहीं… मेरा RAID या मेरा logical volume manager वह करता है।” और truly, यह ZFS the filesystem नहीं है जो RAIDZ provide कर रहा है, यह ZFS the software RAID subsystem है जो ऐसा कर रहा है।

बहुत large filesystems को gracefully handle करने के लिए, ZFS में data integrity features built की गईं जिनमें पूरे filesystem में एक checksum या hash check शामिल था जो corrupted files को repair करने के लिए inclusive software RAID leverage कर सकता था। यह ZFS filesystems के anticipated size के कारण necessary माना गया था। Filesystem corruption एक rarely seen phenomenon है लेकिन जैसे-जैसे filesystems size में grow होते हैं जोखिम बढ़ता है। ZFS की यह lesser known feature possibly इसकी greatest है।

ZFS ने filesystem checks को handle करने के तरीके को भी बदला। इस assumption के कारण कि ZFS बहुत large filesystems पर उपयोग किया जाएगा, एक genuine fear था कि boot time पर filesystem check impossibly long समय ले सकती है और इसलिए एक alternative strategy मिली। Reboot पर check करने का इंतजार करने के बजाय system को एक scrubbing process run करने की जरूरत होगी और system running होते समय एक similar check perform करना होगा। इसके लिए system के live होते अधिक system overhead की जरूरत है लेकिन system unexpected restart से अधिक rapidly recover करने में able है। एक trade off लेकिन एक जिसे widely बहुत positive देखा जाता है।

ZFS के अपने logical volume layer में powerful snapshotting capabilities हैं और इसके RAID layer में बहुत robust caching mechanisms implement की गई हैं जो ZFS को कई use cases के लिए एक excellent choice बनाती हैं। ये features ZFS में unique नहीं हैं बल्कि ZFS से older systems में widely available हैं। हालाँकि, ये प्रत्येक के बहुत अच्छे implementations हैं और ZFS की nature के कारण बहुत well integrated हैं।

एक समय, ZFS open source था और उस era में इसका code Apple के Mac OSX और FreeBSD operating systems का एक part बन गया क्योंकि वे ZFS license के साथ compatible थे। Linux को उस समय ZFS नहीं मिला licensing के आसपास challenges के कारण। यदि ZFS licensing ने Linux को इसे unencumbered उपयोग करने की अनुमति दी होती तो Linux landscape आज शायद बहुत different होता। Mac OSX ने eventually ZFS drop किया क्योंकि इसे उस environment में justify करने के लिए enough advantages नहीं माने गए। FreeBSD ने ZFS को cling किया और, समय के साथ, यह platform पर सबसे popular filesystem बन गया हालाँकि UFS अभी भी heavily उपयोग किया जाता है। Oracle ने Sun acquisition के बाद ZFS का source close किया जिससे FreeBSD को अपने version के ZFS के continuing updates के बिना छोड़ दिया जबकि Oracle Solaris के लिए internally ZFS develop करता रहा।

आज Solaris original ZFS implementation का उपयोग कर रहा है जो अब open source community के साथ split के बाद से कई updates के साथ है। FreeBSD और अन्य ने ZFS को उस state में उपयोग करना जारी रखा जब code closed source था, Oracle के latest updates तक अब access नहीं था। Eventually abandoned open source ZFS codebase को update करने का काम shuru किया गया और अब इसे OpenZFS के रूप में जाना जाता है। OpenZFS अभी भी fledgling है और अभी तक really अपनी mark नहीं बनाई है लेकिन open source space में ZFS platform को revitalize करने की कुछ potential है लेकिन इस समय, OpenZFS अभी भी ZFS से पीछे है।

इस space में पिछले कई वर्षों से open source development ZFS के नए rival BtrFS पर अधिक focus रही है जो natively Linux पर develop हो रहा है और कई major operating system vendors से well supported है। BtrFS बहुत nascent है लेकिन implemented features में ZFS के साथ feature parity तक पहुँचने के लिए major strides कर रहा है लेकिन large aspirations हैं और ZFS की closed source nature के कारण market moment का benefit है। BtrFS, ZFS की तरह, Oracle द्वारा शुरू किया गया था और widely Oracle के future के view के रूप में देखा गया है, Oracle पर भी ZFS के replacement के रूप में। इस समय BtrFS ने already, ZFS की तरह, filesystem, logical volume management और software RAID layers को merge किया है, filesystem integrity के लिए checksumming implement की है, ZFS से भी larger scale होता है (same absolute limit लेकिन अधिक files handle करता है), copy on write snapshots आदि।

ZFS, बिना किसी संदेह के, अपने heyday में एक amazing filesystem था और आज भी एक leader बना हुआ है। मैं 2005 में इसका proponent था और मैं अभी भी इस पर heavily believe करता हूँ। लेकिन ZFS के आसपास community को एक fervor और zealotry लेते देखना मुझे दुखी करता है जो इसकी कोई service नहीं करता और ZFS का mention करना लगभग negative लगने लगता है – ZFS को उन कारणों से universally choose किया जाना जो सब गलत हैं: primarily एक belief कि इसकी features कहीं और exist नहीं करतीं, कि इसका RAID उन risks और limitations के अधीन नहीं है जो उन RAID levels हमेशा अधीन होते हैं या कि इसे एक अलग purpose (primarily performance) के लिए design किया गया था जिसके लिए इसे design नहीं किया गया था। और जब ZFS एक good choice है, तो इसे अक्सर untrue assumptions के based पर poorly implement किया जाता है।

ZFS, ज़ाहिर है, blame नहीं है। न ही, जहाँ तक मैं बता सकता हूँ, इसके corporate supporters या इसके open source developers। जहाँ ZFS को wrong लगता है वह एक loose, unofficial community में है जो हाल ही में ZFS को जाना है, अक्सर यह विश्वास करते हुए कि यह new या “next generation” है क्योंकि उन्होंने हाल ही में इसे discover किया है। मैंने जो देखा है उससे यह almost never Solaris या FreeBSD channels के माध्यम से नहीं बल्कि almost exclusively smaller businesses के लिए है जो FreeNAS या NAS4Free जैसे packaged “NAS OS” उपयोग करना चाहते हैं जो UNIX OSes से familiar नहीं हैं। Packaged NAS OSes का उपयोग, primarily उन IT shops द्वारा जिनके पास न तो deep UNIX न storage skills हैं और, consequently, Windows के बाहर filesystems की broader world के बारे में बहुत कम exposure और अक्सर logical volume management और RAID के प्रति कोई exposure नहीं, especially software RAID, ZFS के आसपास एक “myth” culture की ओर ले जाता प्रतीत होता है जहाँ यह एक almost unquestionable, infallible status ले लेता है।

यह cult-like following और ZFS की general misunderstanding अक्सर ZFS के misapplications या bad assumptions पर based decision making की chain की ओर ले जाती है जो एक को बहुत astray ले जा सकती है।

इस space में सबसे amazing changes में से एक hardware RAID से software RAID में following का change है। Traditionally, software RAID Windows administration circles में एक pariah था बिना किसी अच्छे कारण के – Windows administrators और small businesses, larger UNIX servers से unfamiliar होने के कारण, मानते थे कि hardware RAID ubiquitous था जबकि, reality में, larger scale systems ने always software RAID उपयोग किया। Hardware RAID को, almost industry wide, एक necessity माना जाता था और software RAID completely eschewed था। वही audience, अब “Cult of ZFS” movement के सामने, exactly opposite तरीके से react करते हैं यह मानते हुए कि hardware RAID bad है और ZFS का software RAID ही एकमात्र viable option है। Shift dramatic है और न तो approach valid है – hardware और software RAID दोनों और दोनों कई implementations में बहुत valid options हैं और यहाँ तक कि ZFS उपयोग करते हुए भी hardware RAID का उपयोग easily appropriate हो सकता है।

ZFS को अक्सर इसलिए choose किया जाता है क्योंकि यह माना जाता है कि यह filesystems में highest performance option है लेकिन यह कभी ZFS का key design goal नहीं था। इसे इतने large scale तक scale करने और storage के इतने अलग-अलग aspects handle करने की अनुमति देने वाली features actually highly performant होना बहुत मुश्किल बना देती हैं। ZFS, अपने creation के समय, यहाँ तक कि venerable UFS जितना fast होने की उम्मीद नहीं थी जो same systems पर run करता था। हालाँकि, यह अक्सर इस fact से secondary है कि filesystem performance widely moot है क्योंकि सभी modern filesystems extremely fast हैं और filesystem speed rarely एक important factor है – विशेष रूप से बहुत large, high end storage systems पर एक very large scale के बाहर।

Phoronix द्वारा 2013 में Linux पर ten filesystems का एक interesting study ने workload के अनुसार filesystems में massive differences दिखाईं लेकिन overall performance के रूप में कोई clear winners नहीं थे। Study ने conclusively यह दिखाया कि workload को filesystem से match करना सबसे important choice है, कि ZFS अपने अधिक modern implementations में भी सभी mainstream filesystems के slower side पर आता है और कि बिना workload की बहुत deep understanding के performance reasons के लिए filesystem choose करने से unpredictable performance होगी – यदि performance एक important factor है तो कोई भी filesystem blindly नहीं choose करना चाहिए। दुख की बात है, क्योंकि test Linux पर किया गया था, इसमें UFS की कमी थी जो अक्सर ZFS का key competitor है विशेष रूप से Solaris और FreeBSD पर और इसमें Mac OSX से HFS+ की कमी थी।

Hardware RAID से software RAID में move करने पर additional, अक्सर unforeseen risks भी हैं उन shops के लिए जो UNIX में experienced नहीं हैं। जबकि ZFS hot swapping की अनुमति देता है, यह अक्सर भूल जाया जाता है कि hot swap primarily hardware की feature है, software की नहीं, और यह भी widely unknown है कि blind swapping (operating system में first offline किए बिना hard drives को remove करना) hot swapping के synonymous नहीं है और यह उन shops के लिए disasters ला सकता है जो hardware RAID की tradition से move कर रहे हैं जिसने compatibility, hot swap और blind swapping को उनके लिए transparently handle किया था एक ऐसे software RAID system पर जिसे safely उपयोग करने के लिए system की बहुत अधिक planning, coordination और understanding की जरूरत है।

ZFS की एक lesser, लेकिन अभी भी common misconception यह है कि यह shared DAS या SAN scenarios a la OCFS, VxFS और GFS2 पर उपयोग के लिए एक clustered filesystem है। ZFS एक clustered filesystem नहीं है और उस space में अपने सभी common competitors की तरह same limitations share करता है।

ZFS एक excellent choice हो सकता है लेकिन यह एकमात्र नहीं है। ZFS large caveats के साथ आता है, जिनमें सबसे कम इससे associated operating system limitations नहीं हैं, और जबकि इसके कई benefits हैं कुछ, यदि कोई, ZFS के unique हैं और यह बहुत rare है कि कोई भी shop उन सभी से benefit करे। किसी भी technology की तरह, trade offs करने होते हैं। One size does not fit all। यह जानने की key कि ZFS आपके लिए कब right है, यह समझना है कि ZFS क्या है, इसके बारे में क्या unique है और क्या नहीं, इसके design goals क्या हैं, एक storage को एक pure filesystem के विरुद्ध compare करने से कैसे misleading results मिलते हैं और इससे कौन सी inherent limitations tied हैं।

ZFS एक key consideration है और जब Solaris या FreeBSD chosen operating system है तब common choice। Rare exception के साथ, ZFS के लिए operating system कभी choose नहीं करना चाहिए, बल्कि ZFS को अक्सर choose करना चाहिए, लेकिन हमेशा नहीं, जब operating system choose हो जाए। OS को सबसे rare cases को छोड़कर सभी में filesystem choices drive करनी चाहिए। Operating system की choice filesystem की choice से dramatically अधिक important है।

ZFS को Linux पर उपयोग किया जा सकता है लेकिन वहाँ enterprise option नहीं माना जाता बल्कि experimentation के लिए एक hobby system माना जाता है क्योंकि कोई enterprise vendor (जैसे Red Hat, Suse या Canonical) Linux पर ZFS support नहीं करता और क्योंकि Linux में पहले से ही great alternatives हैं। एक दिन ZFS को Linux में first class filesystem के रूप में promote किया जा सकता है लेकिन यह उम्मीद नहीं है क्योंकि BtrFS already mainline kernel में enter हो चुका है और कई major vendors के production releases में शामिल हो चुका है।

जबकि ZFS Solaris और FreeBSD deployments के vast majority में देखा जाएगा, यह primarily इसलिए है क्योंकि यह default filesystem की position में move हो गया है न कि इसलिए कि यह clearly उन instances में superior choice है या even critically evaluate किया गया है। ZFS उन जगहों पर general purpose filesystem होने के लिए perfectly well suited है जहाँ यह native और supported है।

ZFS का primary use case क्या है?

ZFS का design goal और principal use case Solaris और FreeBSD open storage systems के लिए है जो या तो अन्य servers को shared storage provide करते हैं या locally installed applications के लिए massive data repositories के रूप में काम करते हैं। इन cases में, ZFS का scalability और data integrity पर focus really shine करता है। ZFS heavily large और enterprise scale shops की ओर lean करता है और generally small और medium business space में applicability से दूर जहाँ Solaris और FreeBSD skills, साथ ही large scale storage needs, rare हैं।

Reference: http://www.phoronix.com/scan.php?page=article&item=linux_310_10fs&num=1