فرقه ZFS

در دایره‌های IT بسیار رایج است که ذهنیت فرقه‌مانند یا «فن‌بوی» ایجاد شود. آنچه باعث این واکنش به فناوری‌ها و محصولات می‌شود مطمئن نیستم، اما اینکه اتفاق می‌افتد انکارناپذیر است. یک حوزه‌ای که هرگز فکر نمی‌کردم این اتفاق بیفتد در حوزه سیستم‌های فایل است - یکی از اجزای سیستم «زیر کاپوت» و یکی که تا اخیراً حتی در دایره‌های نسبتاً فنی کوچک‌ترین توجهی دریافت نمی‌کرد. بیایید صادق باشیم، سوءتفاهم در مورد اینکه چه چیزی از Active Directory می‌آید در مقابل آنچه از NTFS می‌آید تقریباً همه‌گیر است. سیستم‌های فایل، به سادگی، نادیده گرفته می‌شوند. از زمانی که Windows NT 4 منتشر شد و NTFS تنها گزینه قابل قبول بود، ایده اینکه یک سیستم فایل یک جزء ذاتی سیستم عامل نیست و ممکن است گزینه‌های دیگری برای ذخیره‌سازی فایل وجود داشته باشد تقریباً محو شده است. یعنی تا اخیراً.

یک جامعه‌ای که تا حدی کمی این اتفاق نیفتاد جامعه Linux بود، اما حتی در آنجا هم Ext2 و نسل‌های آن آنقدر کاملاً در ذهنیت برنده شدند که حتی اگر به طور گسترده در دسترس بودند، سیستم‌های فایل جایگزین به حاشیه رانده شدند و تنها XFS به صورت تاریخی توجهی دریافت کرد، و حتی آن هم توجه بسیار کمی دریافت کرد.

جایی که برخی رفتارهای واقعاً عجیب رخ داده، اخیراً، در اطراف سیستم فایل ZFS Oracle است که در ابتدا برای سیستم عامل Solaris و پلتفرم ذخیره‌سازی باز X4500 «Thumper» توسعه یافت (ابتدا تحت نظارت Sun قبل از خرید Oracle.) در آن زمان (نه سال پیش) که ZFS منتشر شد، سیستم‌های فایل رقیب عمدتاً آماده مدیریت آرایه‌های دیسک بزرگ که انتظار می‌رفت در سال‌های آینده ساخته شوند نبودند. ZFS برای مدیریت آن‌ها طراحی شد و عصر سیستم‌های فایل مقیاس بزرگ را اعلام کرد. مانند اکثر سیستم‌های فایل در آن زمان، ZFS تنها محدود به یک سیستم عامل بود و بنابراین، در حالی که به عنوان یک جهش بزرگ به جلو در طراحی سیستم فایل شناخته می‌شد، موج‌های کمی در دنیای ذخیره‌سازی و حتی کمتر در دنیای «سیستم‌ها» ایجاد کرد که در آن حتی مدیران Solaris عموماً آن را برای مدت طولانی فقط یک نقطه مورد علاقه تلقی می‌کردند و عمدتاً ترجیح می‌دادند به UFS آزموده‌ای که سال‌ها استفاده می‌کردند پایبند باشند.

ZFS، واقعاً، یک سیستم فایل پیشگامانه بود و من بودم و هستم، یک طرفدار بزرگ آن. اما بسیار مهم است که بدانیم ZFS چرا کاری که کرد انجام داد، اهداف آن چیست، چرا آن اهداف مهم بودند و چگونه امروز برای ما کاربرد دارد. پیچیدگی ZFS منجر به سردرگمی و سوءتفاهم زیادی درباره نحوه کار سیستم فایل و زمانی که استفاده از آن مناسب است شده است.

اهداف اصلی ZFS ایجاد یک سیستم فایل قادر به مقیاس‌پذیری خوب برای آرایه‌های دیسک بسیار بزرگ بود. در زمان معرفی آن، مقیاسی که ZFS توانایی آن را داشت در سایر سیستم‌های فایل بی‌سابقه بود اما هیچ نیاز دنیای واقعی برای اینکه یک سیستم فایل بتواند تا آن اندازه بزرگ شود وجود نداشت. تا زمانی که نیاز پیش آمد، بسیاری از سیستم‌های فایل دیگر مانند NTFS، XFS، Ext3 و سایرین برای برآوردن نیاز مقیاس‌پذیر شده بودند. ZFS مطمئناً پیشرو در مدیریت سیستم‌های فایل بزرگ‌تر بود اما به زودی توسط بسیاری دیگر ملحق شد.

از آنجایی که ZFS در دنیای Solaris سرچشمه گرفت که مانند تمام سیستم‌های UNIX آهن بزرگ، RAID سخت‌افزاری وجود ندارد، باید از RAID نرم‌افزاری استفاده می‌شد. Solaris همیشه RAID نرم‌افزاری به عنوان زیرسیستم خودش در دسترس داشت. تصمیم گرفته شد که یک پیاده‌سازی RAID نرم‌افزاری جدید مستقیماً در ZFS ساخته شود. این اجازه می‌داد مدیریت ساده‌شده از طریق یک مجموعه ابزار واحد برای هر دو لایه RAID و سیستم فایل انجام شود. هیچ تغییر یا مزیت قابل توجهی به ZFS معرفی نکرد، همانطور که اغلب تصور می‌شود، صرفاً رابط لایه RAID نرم‌افزاری را از داشتن مجموعه فرمان خودش به بخشی از مجموعه فرمان ZFS تغییر داد.

پیاده‌سازی ZFS از RAID استریپ‌های با عرض متغیر را در سطوح RAID با پاریتی معرفی کرد. این نوآوری یک ریسک جزئی RAID با پاریتی معروف به «حفره نوشتن» را بست. این نوآوری بسیار خوب بود اما بسیار دیر آمد زیرا عصر RAID با پاریتی قابل اطمینان در حال پایان بود و مشکل حفره نوشتن قبلاً به عنوان یک ریسک «نویز پس‌زمینه» بدون ذکر آرایه‌های پاریتی در نظر گرفته می‌شد زیرا عموماً از طریق استفاده از کش‌های آرایه با پشتیبان باتری و، در همان زمان تقریباً، کش‌های آرایه غیر فرار - از دست دادن برق را اجتناب کنید و از حفره نوشتن اجتناب می‌کنید، یک تهدید تلقی نمی‌شد. ZFS نیاز داشت این مشکل را رفع کند زیرا به عنوان RAID نرم‌افزاری، در معرض خطر بیشتر حفره نوشتن نسبت به RAID سخت‌افزاری بود زیرا هیچ فرصتی برای یک کش محافظت‌شده در برابر قطع برق وجود ندارد - RAID سخت‌افزاری پتانسیل یک لایه حفاظت قدرت اضافی برای آرایه‌ها را ارائه می‌دهد.

«نوآوری» واقعی که ZFS به طور تصادفی انجام داد این بود که به جای اینکه فقط سطوح معمول RAID 1، 5، 6 و 10 را پیاده‌سازی کند، آن‌ها را با قراردادهای نام‌گذاری خودشان «برند» کردند. RAID 5 به عنوان RAIDZ شناخته می‌شود. RAID 6 به عنوان RAIDZ2 شناخته می‌شود. RAID 1 فقط به عنوان آینه‌سازی شناخته می‌شود. و به همین ترتیب. این در آن زمان به طور گسترده احمقانه و گیج‌کننده بی‌معنی تلقی می‌شد اما، همانطور که معلوم شد، آن سردرگمی سنگ بنای احیای ZFS سال‌ها بعد شد.

باید توجه داشت که ZFS بعداً اولین پیاده‌سازی تولیدی صنعت از یک RAID 7 (معروف به RAID 7.3) سیستم RAID با پاریتی سه‌گانه را اضافه کرد و آن را RAIDZ3 نام‌گذاری کرد. این اضافه‌شدن بعدی یک نوآوری مهم برای آرایه‌های مقیاس بزرگ است که به بیشترین ظرفیت نیاز دارند در حالی که بسیار ایمن هستند اما حاضرند عملکرد را فدا کنند. این همچنان یک ویژگی منحصر به فرد ZFS است اما به ندرت استفاده می‌شود.

در راستای فشرده‌سازی پشته ذخیره‌سازی و استفاده از یک مجموعه فرمان واحد برای مدیریت تمام جنبه‌های ذخیره‌سازی، توابع مدیریت حجم منطقی نیز در ZFS ادغام شدند. اغلب به اشتباه تصور می‌شود که ZFS مدیریت حجم منطقی را در برخی دایره‌ها معرفی کرد اما تقریباً تمام پلتفرم‌های سازمانی، از جمله AIX، Linux، Windows و حتی خود Solaris، از قبل مدیریت حجم منطقی داشتند. ZFS این کار را برای معرفی یک پارادایم جدید انجام نمی‌داد بلکه صرفاً برای تجمیع مدیریت و بسته‌بندی هر سه لایه ذخیره‌سازی کلیدی (RAID، مدیریت حجم منطقی و سیستم فایل) در یک موجودیت واحد که مدیریت آسان‌تری داشت و می‌توانست ارتباطات ذاتی را در طول پشته فراهم کند. مزایا و معایبی برای این روش وجود دارد و نظر صنعت تقریباً یک دهه بعد هنوز شکل نگرفته است.

یکی از مهم‌ترین جنبه‌های این تجمیع سه سیستم در یک این است که اکنون یک محصول بسیار گیج‌کننده برای بحث داریم. ZFS یک سیستم فایل است، بله، اما نه فقط یک سیستم فایل. یک مدیر حجم منطقی است، اما نه فقط یک مدیر حجم منطقی. مردم به ZFS به عنوان یک سیستم فایل اشاره می‌کنند، که عملکرد اصلی آن است، اما اینکه بسیار بیشتر از یک سیستم فایل است می‌تواند بسیار گیج‌کننده باشد و مقایسه با سایر سیستم‌های ذخیره‌سازی را دشوار می‌کند. در آن زمان معتقدم که این سردرگمی پیش‌بینی نشده بود.

آنچه از این ادغام گیج‌کننده به وجود آمده این است که ZFS اغلب با سایر سیستم‌های فایل مانند XFS یا Ext4 مقایسه می‌شود. اما این گیج‌کننده است زیرا ZFS یک پشته کامل است و XFS فقط یک جنبه از یک پشته است. ZFS بهتر است با MD (RAID نرم‌افزاری Linux) / LVM / XFS یا با SmartArray (RAID سخت‌افزاری HP) / LVM / XFS مقایسه شود تا با XFS به تنهایی. در غیر این صورت به نظر می‌رسد که ZFS پر از ویژگی‌هایی است که XFS فاقد آن‌هاست اما در واقع، این فقط یک پیروزی معنایی است. بیشتر ویژگی‌هایی که اغلب توسط طرفداران ZFS تبلیغ می‌شوند از ZFS سرچشمه نگرفتند و از مدت‌ها قبل از وجود ZFS با سیستم‌های فایل جایگزین در دسترس بودند. اما مقایسه «آیا سیستم فایل شما این کار را می‌کند» دشوار است زیرا پاسخ «نه... RAID یا مدیر حجم منطقی من این کار را می‌کند.» است. و واقعاً، این ZFS سیستم فایل نیست که RAIDZ را ارائه می‌دهد، بلکه ZFS زیرسیستم RAID نرم‌افزاری است که این کار را انجام می‌دهد.

برای مدیریت ظریفانه سیستم‌های فایل بسیار بزرگ، ویژگی‌های یکپارچگی داده در ZFS ساخته شد که شامل یک بررسی چک‌سوم یا هش در سراسر سیستم فایل بود که می‌توانست از RAID نرم‌افزاری مستقر برای تعمیر فایل‌های خراب استفاده کند. این به دلیل اندازه پیش‌بینی‌شده سیستم‌های فایل ZFS در آینده ضروری تلقی شد. خرابی سیستم فایل پدیده‌ای است که به ندرت دیده می‌شود اما با رشد سیستم‌های فایل ریسک افزایش می‌یابد. این ویژگی کمتر شناخته‌شده ZFS احتمالاً بزرگ‌ترین آن است.

ZFS همچنین نحوه انجام بررسی‌های سیستم فایل را تغییر داد. به دلیل فرض اینکه ZFS روی سیستم‌های فایل بسیار بزرگ استفاده خواهد شد، ترس واقعی وجود داشت که یک بررسی سیستم فایل در زمان بوت می‌توانست به طور ناممکنی طولانی به پایان برسد و بنابراین یک استراتژی جایگزین پیدا شد. به جای انتظار برای انجام یک بررسی در راه‌اندازی مجدد، سیستم نیاز به اجرای یک فرآیند اسکراب دارد و یک بررسی مشابه را در حالی که سیستم در حال اجرا است انجام می‌دهد. این به سربار سیستم بیشتری در حالی که سیستم زنده است نیاز دارد اما سیستم قادر است پس از یک راه‌اندازی مجدد غیر منتظره سریع‌تر بازیابی شود. یک مبادله اما یکی که به طور گسترده بسیار مثبت تلقی می‌شود.

ZFS توانایی‌های عکس‌برداری قدرتمندی در لایه حجم منطقی خود دارد و در لایه RAID خود مکانیزم‌های کش بسیار قوی پیاده‌سازی کرده است که ZFS را برای بسیاری از موارد استفاده انتخاب عالی می‌کند. این ویژگی‌ها در ZFS منحصر به فرد نیستند اما به طور گسترده در سیستم‌هایی قدیمی‌تر از ZFS موجود هستند. با این حال، آن‌ها پیاده‌سازی‌های بسیار خوبی از هر کدام هستند و به دلیل ماهیت ZFS بسیار خوب ادغام شده‌اند.

در یک زمان، ZFS متن باز بود و در آن دوره کد آن بخشی از سیستم‌های عامل Mac OSX Apple و FreeBSD شد زیرا با مجوز ZFS سازگار بودند. Linux در آن زمان ZFS را نگرفت به دلیل چالش‌های مجوزدهی. اگر مجوزدهی ZFS به Linux اجازه می‌داد بدون مانع از آن استفاده کند، چشم‌انداز Linux امروز احتمالاً بسیار متفاوت بود. Mac OSX در نهایت ZFS را رها کرد زیرا مزایای کافی برای توجیه آن در آن محیط دیده نمی‌شد. FreeBSD به ZFS چسبید و، با گذشت زمان، به محبوب‌ترین سیستم فایل در پلتفرم تبدیل شد اگرچه UFS هنوز هم به طور گسترده استفاده می‌شود. Oracle پس از خرید Sun منبع ZFS را بست و FreeBSD را بدون به‌روزرسانی‌های مداوم برای نسخه ZFS خود رها کرد در حالی که Oracle به توسعه ZFS به صورت داخلی برای Solaris ادامه داد.

امروز Solaris همچنان از پیاده‌سازی اصلی ZFS با چندین به‌روزرسانی از زمان جدایی آن از جامعه متن باز استفاده می‌کند. FreeBSD و سایرین به استفاده از ZFS در حالتی که کد بسته شد ادامه دادند و دیگر به جدیدترین به‌روزرسانی‌های Oracle دسترسی ندارند. در نهایت کار به‌روزرسانی پایگاه کد ZFS متن باز رها شده آغاز شد و اکنون به عنوان OpenZFS شناخته می‌شود. OpenZFS هنوز در مراحل اولیه است و هنوز واقعاً جای خود را پیدا نکرده اما پتانسیلی برای احیای پلتفرم ZFS در فضای متن باز دارد اما در این زمان، OpenZFS هنوز از ZFS عقب است.

توسعه متن باز در چند سال گذشته در این حوزه بیشتر بر روی رقیب جدید ZFS یعنی BtrFS متمرکز شده که به صورت بومی روی Linux توسعه می‌یابد و از بسیاری از فروشندگان عمده سیستم عامل پشتیبانی خوبی دریافت می‌کند. BtrFS بسیار جوان است اما در حال پیشرفت‌های عمده‌ای برای رسیدن به برابری ویژگی با ZFS در ویژگی‌های پیاده‌سازی‌شده است اما آرزوهای بزرگی دارد و به دلیل ماهیت منبع بسته ZFS از مومنتوم بازار بهره می‌برد. BtrFS مانند ZFS توسط Oracle شروع شد و به طور گسترده به عنوان دیدگاه Oracle برای آینده به عنوان جایگزینی برای ZFS حتی در Oracle تلقی شده است. در این زمان BtrFS مانند ZFS قبلاً لایه‌های سیستم فایل، مدیریت حجم منطقی و RAID نرم‌افزاری را ادغام کرده، چک‌سام برای یکپارچگی سیستم فایل پیاده‌سازی کرده، مقیاس حتی بزرگ‌تری از ZFS دارد (همان حد مطلق اما فایل‌های بیشتری مدیریت می‌کند)، عکس‌برداری کپی در هنگام نوشتن و غیره.

ZFS، بدون شک، در دوران اوج خود یک سیستم فایل شگفت‌انگیز بود و امروز هم یک رهبر است. در سال 2005 طرفدار آن بودم و هنوز هم به شدت به آن اعتقاد دارم. اما این مرا ناراحت کرده که ببینم جامعه اطراف ZFS حرارت و تعصبی به خود گرفته که به آن خدمتی نمی‌کند و ذکر ZFS را تقریباً منفی به نظر می‌رساند - ZFS آنقدر به طور جهانی به دلایل اشتباه انتخاب می‌شود: عمدتاً این باور که ویژگی‌هایش در هیچ جای دیگری وجود ندارند، که RAID آن مشمول ریسک‌ها و محدودیت‌هایی که آن سطوح RAID همیشه مشمولشان هستند نمی‌شود یا اینکه برای هدفی متفاوت (عمدتاً عملکرد) طراحی شده که برای آن طراحی نشده است. و هنگامی که ZFS انتخاب خوبی است، اغلب بر اساس فرضیات نادرست به شکل ضعیفی پیاده‌سازی می‌شود.

ZFS البته مقصر نیست. نه حامیان شرکتی آن و نه توسعه‌دهندگان متن باز آن تا آنجا که می‌توانم بگویم. جایی که ZFS به نظر می‌رسد از مسیر خارج شده در یک جامعه غیررسمی و غیر محکم است که اخیراً ZFS را شناخته، اغلب با این باور که جدید یا «نسل بعدی» است زیرا آن را تازه کشف کرده‌اند. از آنچه دیده‌ام این تقریباً هرگز از طریق کانال‌های Solaris یا FreeBSD نیست بلکه تقریباً منحصراً کسب‌وکارهای کوچک‌تری هستند که به دنبال استفاده از یک «سیستم عامل NAS» بسته مانند FreeNAS یا NAS4Free هستند که با سیستم‌های عامل UNIX آشنا نیستند. استفاده از سیستم‌های عامل NAS بسته، عمدتاً توسط مغازه‌های IT که نه مهارت‌های عمیق UNIX و نه مهارت‌های ذخیره‌سازی دارند و در نتیجه، کمی در معرض دنیای گسترده‌تر سیستم‌های فایل خارج از Windows هستند و اغلب کم یا هیچ در معرض مدیریت حجم منطقی و RAID، به ویژه RAID نرم‌افزاری، نبوده‌اند، به نظر می‌رسد به یک فرهنگ «اسطوره» اطراف ZFS منجر می‌شود که آن را به یک وضعیت تقریباً غیر قابل بحث و خطاناپذیر می‌رساند.

این پیروی فرقه‌مانند و سوءتفاهم کلی از ZFS اغلب به کاربردهای نادرست ZFS یا زنجیره‌ای از تصمیم‌گیری بر اساس فرضیات بد منجر می‌شود که می‌تواند کسی را بسیار گمراه کند.

یکی از شگفت‌انگیزترین تغییرات در این حوزه تغییر در پیروی از RAID سخت‌افزاری به RAID نرم‌افزاری است. به طور سنتی، RAID نرم‌افزاری در دایره‌های مدیریت Windows بدون دلیل خوبی منفور بود - مدیران Windows و کسب‌وکارهای کوچک، که اغلب با سرورهای UNIX مقیاس بزرگ‌تر ناآشنا بودند، معتقد بودند که RAID سخت‌افزاری همه‌گیر است در حالی که، در واقع، سیستم‌های با مقیاس بزرگ‌تر همیشه از RAID نرم‌افزاری استفاده می‌کردند. RAID سخت‌افزاری، تقریباً در سراسر صنعت، یک ضرورت تلقی می‌شد و RAID نرم‌افزاری کاملاً نادیده گرفته می‌شد. همان مخاطبان، که حالا با جنبش «فرقه ZFS» مواجه هستند، دقیقاً به روش مخالف واکنش نشان می‌دهند و معتقدند که RAID سخت‌افزاری بد است و RAID نرم‌افزاری ZFS تنها گزینه قابل قبول است. این تغییر چشمگیر است و هیچ یک از این رویکردها معتبر نیست - هر دو RAID سخت‌افزاری و نرم‌افزاری و هر دو در بسیاری از پیاده‌سازی‌ها گزینه‌های بسیار معتبری هستند و حتی با استفاده از ZFS استفاده از RAID سخت‌افزاری ممکن است کاملاً مناسب باشد.

ZFS اغلب به این دلیل انتخاب می‌شود که باور می‌شود بالاترین گزینه عملکردی در سیستم‌های فایل است اما این هرگز یک هدف طراحی کلیدی ZFS نبود. ویژگی‌هایی که به آن اجازه می‌دهد تا این حد مقیاس بزرگ شود و جنبه‌های بسیار مختلف ذخیره‌سازی را مدیریت کند، عملکرد بالا را بسیار دشوار می‌کند. ZFS، در زمان ایجادش، حتی انتظار نمی‌رفت که به سریع UFS که روی همان سیستم‌ها اجرا می‌شد باشد. با این حال، این اغلب ثانوی است به این واقعیت که عملکرد سیستم فایل به طور گسترده بی‌اهمیت است زیرا تمام سیستم‌های فایل مدرن بسیار سریع هستند و سرعت سیستم فایل به ندرت یک عامل مهم است - به ویژه خارج از سیستم‌های ذخیره‌سازی بسیار بزرگ و سطح بالا در مقیاس بسیار زیاد.

یک مطالعه جالب از ده سیستم فایل روی Linux که توسط Phoronix در سال 2013 تولید شد تفاوت‌های عظیمی در سیستم‌های فایل بر اساس بار کاری نشان داد اما هیچ برنده‌ای از نظر عملکرد کلی مشخص نبود. آنچه مطالعه به طور قطعی نشان داد این است که تطبیق بار کاری با سیستم فایل مهم‌ترین انتخاب است، که ZFS در سمت کندتر تمام سیستم‌های فایل اصلی حتی در پیاده‌سازی‌های نوین‌تر آن قرار می‌گیرد و اینکه انتخاب یک سیستم فایل به دلایل عملکرد بدون درک بسیار عمیق از بار کاری منجر به عملکرد غیرقابل پیش‌بینی خواهد شد - هیچ سیستم فایلی نباید کورکورانه انتخاب شود اگر عملکرد یک عامل مهم است. متأسفانه، چون آزمون روی Linux انجام شد، UFS را که اغلب رقیب کلیدی ZFS به ویژه در Solaris و FreeBSD است نداشت و HFS+ از Mac OSX Apple را هم نداشت.

انتقال از RAID سخت‌افزاری به RAID نرم‌افزاری ریسک‌های اضافی و اغلب پیش‌بینی‌نشده‌ای برای مغازه‌هایی که در UNIX تجربه ندارند نیز دارد. در حالی که ZFS اجازه تعویض گرم می‌دهد، اغلب فراموش می‌شود که تعویض گرم عمدتاً یک ویژگی سخت‌افزاری است، نه نرم‌افزار، و همچنین به طور گسترده ناشناخته است که تعویض کور (حذف دیسک‌های سخت بدون اول آفلاین کردن آن‌ها در سیستم عامل) مترادف با تعویض گرم نیست و این می‌تواند برای مغازه‌هایی که از سنت RAID سخت‌افزاری که سازگاری، تعویض گرم و تعویض کور را به طور شفاف برای آن‌ها مدیریت می‌کرد به یک سیستم RAID نرم‌افزاری که به برنامه‌ریزی، هماهنگی و درک بسیار بیشتری از سیستم برای استفاده ایمن نیاز دارد منتقل می‌شوند، به فاجعه منجر شود.

یک سوءتفاهم کمتر اما هنوز رایج از ZFS این است که یک سیستم فایل خوشه‌ای مناسب برای استفاده در سناریوهای DAS یا SAN مشترک مانند OCFS، VxFS و GFS2 است. ZFS یک سیستم فایل خوشه‌ای نیست و در آن حوزه همان محدودیت‌هایی که همه رقبای رایج آن دارند را دارد.

ZFS می‌تواند یک انتخاب عالی باشد اما از تنها انتخاب دور است. ZFS با هشدارهای بزرگی همراه است، نه کمترین که محدودیت‌های سیستم عامل مرتبط با آن است، و اگرچه مزایای زیادی دارد کمی اگر هیچ از آن‌ها منحصر به ZFS است و بسیار نادر است که هر مغازه‌ای از همه آن‌ها بهره‌مند شود. مانند هر فناوری، مبادلاتی وجود دارد که باید انجام شود. یک اندازه برای همه مناسب نیست. کلید دانستن اینکه چه زمانی ZFS برای شما مناسب است این است که بدانید ZFS چیست، چه چیزی منحصر به فرد آن است و چه چیزی نیست، اهداف طراحی آن چیستند، چگونه مقایسه یک پشته ذخیره‌سازی با یک سیستم فایل خالص نتایج گمراه‌کننده‌ای تولید می‌کند و چه محدودیت‌های ذاتی به آن متصل هستند.

ZFS یک ملاحظه کلیدی و انتخاب رایج است وقتی Solaris یا FreeBSD سیستم عامل انتخابی است. با استثنای نادر، سیستم عامل هرگز نباید برای ZFS انتخاب شود، بلکه ZFS باید اغلب، اما نه همیشه، انتخاب شود وقتی سیستم عامل انتخاب می‌شود. سیستم عامل باید انتخاب‌های سیستم فایل را در همه موارد به جز نادرترین موارد هدایت کند. انتخاب سیستم عامل به شکل چشمگیری مهم‌تر از انتخاب سیستم فایل است.

ZFS می‌تواند روی Linux استفاده شود اما یک گزینه سازمانی در آنجا نیست بلکه بیشتر یک سیستم سرگرمی برای آزمایش است زیرا هیچ فروشنده سازمانی (مانند Red Hat، Suse یا Canonical) ZFS را روی Linux پشتیبانی نمی‌کند و Linux جایگزین‌های خوبی از قبل دارد. روزی ZFS ممکن است به یک سیستم فایل درجه اول در Linux ارتقاء یابد اما این انتظار نمی‌رود زیرا BtrFS از قبل وارد هسته اصلی شده و در نسخه‌های تولیدی توسط چندین فروشنده عمده گنجانده شده است.

در حالی که ZFS در اکثریت قریب به اتفاق پیاده‌سازی‌های Solaris و FreeBSD دیده می‌شود، این عمدتاً به این دلیل است که به موقعیت سیستم فایل پیش‌فرض منتقل شده و نه به این دلیل که به وضوح انتخاب برتر در آن موارد است یا حتی به صورت انتقادی ارزیابی شده است. ZFS به خوبی به عنوان یک سیستم فایل عمومی در جایی که بومی و پشتیبانی‌شده است مناسب است.

موارد استفاده اصلی ZFS چیست؟

هدف طراحی ZFS و موارد استفاده اصلی آن برای سیستم‌های ذخیره‌سازی باز Solaris و FreeBSD است که ذخیره‌سازی مشترک را برای سایر سرورها فراهم می‌کنند یا به عنوان مخازن داده عظیم برای برنامه‌های نصب‌شده به صورت محلی هستند. در این موارد، تمرکز ZFS بر مقیاس‌پذیری و یکپارچگی داده واقعاً می‌درخشد. ZFS به شدت به سمت مغازه‌های بزرگ و مقیاس سازمانی تمایل دارد و عموماً از کاربرد در فضای کسب‌وکار کوچک و متوسط دور است که مهارت‌های Solaris و FreeBSD، و همچنین نیازهای ذخیره‌سازی مقیاس بزرگ، نادر هستند.

مرجع: http://www.phoronix.com/scan.php?page=article&item=linux_310_10fs&num=1