عبادة ZFS

من الشائع جدًا في أوساط تقنية المعلومات أن تتطور عقلية شبيهة بالطائفة أو عقلية “المعجب المتعصب”. ما الذي يسبب هذا الرد تجاه التقنيات والمنتجات لست متأكدًا تمامًا، لكن أنه يحدث أمر لا يمكن إنكاره. أحد المجالات التي لم أتوقع أبدًا أن أرى هذا يحدث فيها هو مجال أنظمة الملفات، أحد مكونات النظام “تحت الغطاء” الأكثر غموضًا والذي لم يحظَ حتى وقت قريب بأي اهتمام حتى في الأوساط التقنية المعقولة. دعنا نواجه الحقيقة، سوء فهم الفرق بين ما يأتي من Active Directory وما يأتي من NTFS يكاد يكون أمرًا عالميًا. أنظمة الملفات ببساطة مُتجاهَلة. منذ أن أصدر Windows NT 4 وكان NTFS الخيار الوحيد القابل للتطبيق، كادت فكرة أن نظام الملفات ليس مكونًا جوهريًا لنظام التشغيل وأن ثمة خيارات أخرى لتخزين الملفات تتلاشى. أي حتى وقت قريب.

المجتمع الوحيد الذي لم يحدث فيه هذا بدرجة صغيرة إلى حد ما كان مجتمع Linux، لكن حتى هناك فاز Ext2 وأحفاده بالهيمنة الفكرية لدرجة أنه حتى مع توفرها على نطاق واسع، ظلت أنظمة الملفات البديلة على الهامش ولم يحظَ XFS إلا بالقدر الأدنى من الاهتمام تاريخيًا، وحتى ذلك كان قليلًا جدًا.

حيث حدث بعض السلوك الغريب حقًا مؤخرًا هو حول نظام ملفات ZFS الخاص بـ Oracle، الذي طُوِّر أصلًا لنظام تشغيل Solaris ومنصة التخزين المفتوح X4500 “Thumper” (أصلًا تحت إشراف Sun قبل استحواذ Oracle). في وقت إصداره (منذ تسع سنوات) كانت أنظمة الملفات المنافسة غير مستعدة إلى حد بعيد للتعامل مع مصفوفات الأقراص الكبيرة التي كان من المتوقع إنشاؤها في السنوات القادمة. صُمِّم 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 يُعرف ببساطة بالنسخ المرآتي (mirroring). وهكذا. كان هذا يُعتبر على نطاق واسع سخيفًا وربّاكًا بلا داعٍ في وقته لكن كما اتضح لاحقًا، أصبح ذلك الارتباك حجر الزاوية في إحياء ZFS بعد سنوات.

تجدر الإشارة إلى أن ZFS أضاف لاحقًا أول تطبيق إنتاجي في الصناعة لنظام RAID 7 (المعروف أيضًا بـ RAID 7.3) ذي التكافؤ الثلاثي وأطلق عليه RAIDZ3. هذه الإضافة اللاحقة ابتكار مهم للمصفوفات واسعة النطاق التي تحتاج إلى أقصى درجات السعة مع الحفاظ على أمان شديد لكنها مستعدة للتضحية بالأداء في مقابل ذلك. تظل هذه ميزة فريدة لـ ZFS لكنها نادرًا ما تُستخدم.

بروح الجمع بين مكونات التخزين واستخدام مجموعة أوامر واحدة لإدارة جميع جوانب التخزين، أُدرجت وظائف إدارة الأقراص المنطقية في ZFS أيضًا. كثيرًا ما يُعتقد خطأً أن ZFS أدخل إدارة الأقراص المنطقية في بعض الأوساط، لكن تقريبًا جميع المنصات المؤسسية، بما فيها AIX وLinux وWindows وحتى Solaris نفسه، كانت قد امتلكت بالفعل إدارة للأقراص المنطقية لسنوات. لم يكن ZFS يفعل هذا لإدخال نموذج جديد بل ببساطة لدمج الإدارة وتغليف الطبقات التخزينية الثلاث الرئيسية (RAID وإدارة الأقراص المنطقية ونظام الملفات) في كيان واحد أسهل في الإدارة ويمكنه توفير اتصالات متأصلة صعودًا وهبوطًا في المكدّس. لهذه الطريقة إيجابيات وسلبيات ولا تزال الصناعة بلا رأي واضح بشأنها بعد ما يقارب عقدًا من الزمن.

أحد أهم جوانب دمج هذه الأنظمة الثلاثة في نظام واحد هو أننا الآن أمام منتج يصعب مناقشته. ZFS نظام ملفات نعم، لكنه ليس نظام ملفات فحسب. إنه مدير أقراص منطقية لكن ليس فقط ذلك. يشير الناس إلى ZFS بوصفه نظام ملفات وهي وظيفته الرئيسية، لكن أنه أكثر بكثير من مجرد نظام ملفات يمكن أن يكون محيّرًا جدًا ويجعل المقارنات مع أنظمة التخزين الأخرى صعبة. أعتقد في وقتها أن هذا الالتباس لم يكن متوقعًا.

ما نتج عن هذا الدمج المربك هو أن ZFS يُقارن كثيرًا بأنظمة ملفات أخرى كـ XFS أو Ext4. لكن هذا مربك إذ ZFS مكدّس كامل وXFS جزء واحد فقط من مكدّس. يُفضَّل مقارنة ZFS بـ MD (Linux Software RAID) / LVM / XFS أو بـ SmartArray (HP Hardware RAID) / LVM / XFS بدلًا من XFS وحده. وإلا يبدو أن ZFS مليء بميزات تفتقرها XFS في حين أن الواقع أنه انتصار دلالي فحسب. معظم الميزات التي يروّج لها مؤيدو ZFS لم تنشأ مع ZFS وكانت متاحة بشكل شائع مع أنظمة الملفات البديلة قبل وجود ZFS بفترة طويلة. لكن يصعب المقارنة بسؤال “هل يدعم نظام الملفات الخاص بك ذلك” لأن الجواب هو “لا... RAID أو مدير الأقراص المنطقية لديّ يدعم ذلك.” وفعليًا ليس ZFS بوصفه نظام ملفات هو من يوفر RAIDZ بل ZFS بوصفه نظام RAID البرمجي هو من يفعل ذلك.

من أجل التعامل بسلاسة مع أنظمة الملفات الكبيرة جدًا، بُنيت ميزات سلامة البيانات في ZFS والتي شملت التحقق من المجموع الاختباري (checksum) أو التحقق بالدالة التجزيئية (hash) في جميع أنحاء نظام الملفات بإمكانية الاستفادة من RAID البرمجي المُدمَج لإصلاح الملفات التالفة. كان يُنظر إلى هذا على أنه ضرورة بسبب الحجم المتوقع لأنظمة ملفات ZFS في المستقبل. تلف نظام الملفات ظاهرة نادرة لكن مع نمو أنظمة الملفات في الحجم تزداد المخاطر. هذه الميزة الأقل شهرة لـ ZFS هي ربما أعظم ميزاته.

غيّر ZFS أيضًا طريقة التعامل مع فحوصات نظام الملفات. بسبب الافتراض بأن ZFS سيُستخدم على أنظمة ملفات كبيرة جدًا كان ثمة خوف حقيقي من أن فحص نظام الملفات عند بدء التشغيل قد يستغرق وقتًا طويلًا بشكل مستحيل للانتهاء، فوُجد بديل. بدلًا من انتظار إجراء الفحص عند إعادة التشغيل يتطلب النظام تشغيل عملية تنظيف وإجراء فحص مماثل أثناء تشغيل النظام. هذا يتطلب حملًا نظاميًا إضافيًا أثناء تشغيل النظام لكن النظام يستطيع التعافي من إعادة التشغيل غير المتوقعة بشكل أسرع. مقايضة لكنها تُعدّ على نطاق واسع إيجابية جدًا.

يمتلك ZFS قدرات لقطات (snapshots) قوية في طبقة الأقراص المنطقية وفي طبقة RAID طبّق آليات تخزين مؤقت قوية جدًا مما يجعل ZFS خيارًا ممتازًا لحالات استخدام كثيرة. هذه الميزات ليست فريدة لـ ZFS بل متاحة على نطاق واسع في أنظمة أقدم من ZFS. لكنها تطبيقات جيدة جدًا وذات تكامل عالٍ بسبب طبيعة ZFS.

في وقت ما، كان ZFS مفتوح المصدر وخلال تلك الحقبة أصبح كوده جزءًا من نظامَي تشغيل Mac OSX وFreeBSD لأنهما كانا متوافقَين مع رخصة ZFS. لم يحصل Linux على ZFS في ذلك الوقت بسبب تحديات الترخيص. لو كان ترخيص ZFS يتيح لـ Linux استخدامه بلا عوائق لكان مشهد Linux مختلفًا جدًا اليوم. في نهاية المطاف أسقطت Mac OSX دعم ZFS إذ لم يُعدّ ذا مزايا كافية تبرر استمراره في تلك البيئة. تمسّك FreeBSD بـ ZFS وبمرور الوقت أصبح نظام الملفات الأكثر شيوعًا على المنصة رغم أن UFS لا يزال يُستخدم على نطاق واسع. أغلقت Oracle مصدر ZFS بعد استحواذها على Sun تاركةً FreeBSD بلا تحديثات مستمرة لنسخته من ZFS بينما واصلت Oracle تطوير ZFS داخليًا لـ Solaris.

لا يزال Solaris يستخدم تطبيق ZFS الأصلي الذي حصل على عدة تحديثات منذ انفصاله عن مجتمع المصدر المفتوح. استمر FreeBSD وآخرون في استخدام ZFS في الحالة التي كان عليها حين أُغلق الكود، لم يعودوا قادرين على الوصول إلى أحدث تحديثات Oracle. في نهاية المطاف بدأ العمل على تحديث قاعدة كود ZFS المفتوحة المهجورة وأصبحت معروفة الآن باسم OpenZFS. لا يزال OpenZFS في طور النشأة ولم يُثبت نفسه بعد حقًا لكنه يملك بعض الإمكانات لإحياء منصة ZFS في مجال المصدر المفتوح، غير أن OpenZFS لا يزال متأخرًا عن ZFS في هذه المرحلة.

تركّز التطوير مفتوح المصدر في السنوات الأخيرة في هذا المجال أكثر على المنافس الجديد لـ ZFS وهو BtrFS الذي يُطوَّر بشكل أصلي على Linux ومدعوم بشكل جيد من كثير من موردي أنظمة التشغيل الرئيسيين. BtrFS لا يزال في مراحله الأولى لكنه يُحرز تقدمًا كبيرًا نحو تحقيق تكافؤ الميزات مع ZFS في الميزات المُطبَّقة وله طموحات كبيرة. نظرًا للطبيعة المغلقة المصدر لـ ZFS يحظى BtrFS بمزية زخم السوق. بدأ تطوير BtrFS، مثل ZFS، من قبل Oracle وكان يُنظر إليه على نطاق واسع باعتباره رؤية Oracle للمستقبل بوصفه بديلًا لـ ZFS حتى عند Oracle. في هذه المرحلة طبّق BtrFS بالفعل، مثل ZFS، دمج طبقات نظام الملفات وإدارة الأقراص المنطقية وRAID البرمجي، وطبّق التحقق بالمجموع الاختباري لسلامة نظام الملفات، ويتوسع إلى أبعاد أكبر من ZFS (نفس الحد المطلق لكنه يتعامل مع ملفات أكثر)، ولقطات النسخ عند الكتابة (copy on write snapshots)، وغير ذلك.

لا شك أن ZFS كان نظام ملفات مذهلًا في عصره الذهبي ولا يزال رائدًا حتى اليوم. كنت مؤيدًا له في 2005 ولا أزال أؤمن به بشدة. لكن حزنني أن أرى المجتمع المحيط بـ ZFS يتخذ حماسة وتعصبًا لا يخدمانه ويجعلان مجرد ذكر ZFS يبدو سلبيًا، إذ يُختار ZFS بشكل شبه عالمي للأسباب الخاطئة: أساسًا الاعتقاد بأن ميزاته لا توجد في أي مكان آخر، وأن RAID الخاص به غير خاضع للمخاطر والقيود التي تخضع لها دائمًا تلك المستويات من RAID، أو أنه صُمِّم لغرض مختلف (في المقام الأول الأداء) عما صُمِّم من أجله فعلًا. وعندما يكون ZFS خيارًا جيدًا فكثيرًا ما يُطبَّق بشكل سيء استنادًا إلى افتراضات غير صحيحة.

بالطبع ZFS ليس المذنب. وبقدر ما أستطيع تقدير الأمر، لا مؤيدوه الشركاتيون ولا مطوروه من المصدر المفتوح. يبدو أن ZFS قد انحرف في مجتمع غير رسمي فضفاض اكتشف ZFS حديثًا فحسب، معتقدًا في أحيان كثيرة أنه جديد أو “الجيل القادم” لأنهم اكتشفوه للتو. مما رأيت لا يكاد يحدث هذا عبر قنوات Solaris أو FreeBSD بل بشكل شبه حصري من خلال الشركات الصغيرة التي تريد استخدام “نظام تشغيل NAS” مُعبَّأ مثل FreeNAS أو NAS4Free وهي غير دارية بأنظمة UNIX. يبدو أن استخدام أنظمة NAS المُعبَّأة بشكل أساسي من قِبَل متاجر تقنية المعلومات التي لا تمتلك مهارات 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.

الانتقال من RAID الأجهزة إلى RAID البرمجي ينطوي على مخاطر إضافية كثيرًا ما تكون غير متوقعة للمتاجر غير المتمرسة في UNIX. في حين يتيح ZFS التبادل الساخن (hot swap)، كثيرًا ما يُنسى أن التبادل الساخن هو في المقام الأول ميزة للأجهزة لا للبرمجيات، كما أنه من غير المعروف على نطاق واسع أن التبادل الأعمى (إزالة الأقراص الصلبة دون إخراجها أولًا من الخدمة في نظام التشغيل) ليس مرادفًا للتبادل الساخن وهذا يمكن أن يؤدي إلى كوارث للمتاجر المنتقلة من تقليد 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 بالفعل نواة Linux الرئيسية وأُدرج في إصدارات إنتاجية من قِبَل عدة موردين رئيسيين.

بينما سيُشاهَد 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