زد اف اس

📅 آخر تحديث: ١٧ يوليو ٢٠٢٦
✍️ نُشر في: ١٧ يوليو ٢٠٢٦
📷 يحتوي على 4 صور
الموسوعة الحرة

زد اف اس
المطور(ون)Sun Microsystems في الأصل، وOracle Corporation منذ عام 2010، و OpenZFS منذ عام 2013
المتغيراتأوراكل ZFS ، OpenZFS
قدَّمنوفمبر 2005 ؛ منذ 18 عامًا مع OpenSolaris (2005-11)
الهياكل
محتويات الدليلجدول التجزئة القابل للتوسيع
الحدود
الحد الأقصى لحجم الصوت256 تريليون  يوبيبايت (2 128  بايت) [1]
الحد الأقصى لحجم الملف16  بايت إكسبي (2 64  بايت)
الحد الأقصى لعدد الملفات
  • لكل دليل: 2 48
  • لكل نظام ملفات: غير محدود [1]
الحد الأقصى لطول اسم الملف1023 حرفًا من نوع ASCII (أقل بالنسبة لمعايير الأحرف متعددة البايتات مثل Unicode )
سمات
شوكنعم (تسمى "السمات الممتدة"، ولكنها عبارة عن تدفقات كاملة)
صفاتPOSIX ، السمات الممتدة

أذونات نظام الملفات		أذونات يونكس، قوائم التحكم في الوصول NFSv4

ضغط شفاف		نعم

تشفير شفاف		نعم
إزالة تكرار البياناتنعم
نسخ عند الكتابةنعم
آخر
أنظمة التشغيل المدعومة

ZFS ( نظام الملفات Zettabyte سابقًا ) هو نظام ملفات يتمتع بقدرات إدارة وحدة التخزين . بدأ كجزء من نظام التشغيل Sun Microsystems Solaris في عام 2001. تم نشر أجزاء كبيرة من Solaris، بما في ذلك ZFS، بموجب ترخيص مفتوح المصدر باسم OpenSolaris لمدة 5 سنوات تقريبًا من عام 2005 قبل وضعها تحت ترخيص مغلق المصدر عندما استحوذت شركة Oracle Corporation على Sun في 2009-2010. خلال الفترة من 2005 إلى 2010، تم نقل الإصدار مفتوح المصدر من ZFS إلى Linux و Mac OS X (استمر باسم MacZFS ) و FreeBSD . في عام 2010، قام مشروع illumos بتقسيم إصدار حديث من OpenSolaris، بما في ذلك ZFS، لمواصلة تطويره كمشروع مفتوح المصدر. في عام 2013، تم تأسيس OpenZFS لتنسيق تطوير ZFS مفتوح المصدر. [3] [4] [5] تحافظ OpenZFS على كود ZFS الأساسي وتديره، بينما تحافظ المؤسسات التي تستخدم ZFS على الكود المحدد وعمليات التحقق المطلوبة لدمج ZFS داخل أنظمتها. يُستخدم OpenZFS على نطاق واسع في الأنظمة الشبيهة بنظام Unix . [6] [7] [8]

ملخص

تتضمن إدارة البيانات المخزنة عمومًا جانبين: إدارة الحجم المادي لجهاز تخزين كتلة واحد أو أكثر (مثل محركات الأقراص الصلبة وبطاقات SD )، بما في ذلك تنظيمها في أجهزة كتلة منطقية مثل VDEVs (جهاز ZFS الظاهري) [9] كما يراها نظام التشغيل (غالبًا ما تنطوي على مدير وحدة تخزين أو وحدة تحكم RAID أو مدير مجموعة أو برنامج تشغيل جهاز مناسب )؛ وإدارة البيانات والملفات المخزنة على أجهزة الكتلة المنطقية هذه ( نظام ملفات أو تخزين بيانات آخر).

مثال: يتم التحكم في مجموعة RAID من محركي أقراص ثابتين وقرص تخزين SSD بواسطة نظام RST من Intel ، وهو جزء من مجموعة الشرائح والبرامج الثابتة المضمنة في جهاز كمبيوتر سطح المكتب. يرى مستخدم Windows هذا كمجلد واحد يحتوي على محرك بتنسيق NTFS لبياناته، ولا يدرك NTFS بالضرورة التلاعبات التي قد تكون مطلوبة (مثل القراءة من/الكتابة إلى محرك التخزين المؤقت أو إعادة بناء مجموعة RAID في حالة فشل القرص). تختلف إدارة الأجهزة الفردية وتقديمها كجهاز واحد عن إدارة الملفات الموجودة على هذا الجهاز الظاهري.

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

يتضمن ZFS أيضًا آلية لالتقاط الصور على مستوى مجموعة البيانات والمجموعة والتكرار ، بما في ذلك استنساخ اللقطات ، والذي وصفته وثائق FreeBSD بأنه أحد "أقوى ميزاته" مع وظيفة "تفتقر إليها حتى أنظمة الملفات الأخرى ذات وظيفة اللقطات". [10] يمكن التقاط عدد كبير جدًا من اللقطات دون تدهور الأداء، مما يسمح باستخدام اللقطات قبل عمليات النظام الخطرة وتغييرات البرامج، أو التقاط صور كاملة لنظام الملفات ("مباشر") عدة مرات في الساعة من أجل التخفيف من فقد البيانات بسبب خطأ المستخدم أو النشاط الضار. يمكن استعادة اللقطات "مباشرة" أو يمكن عرض حالات نظام الملفات السابقة، حتى على أنظمة الملفات الكبيرة جدًا، مما يؤدي إلى توفير مقارنة بعمليات النسخ الاحتياطي والاستعادة الرسمية. [10] يمكن أيضًا استنساخ اللقطات لتشكيل أنظمة ملفات مستقلة جديدة. يتمتع ZFS أيضًا بالقدرة على التقاط لقطة على مستوى المجموعة (المعروفة باسم "نقطة التفتيش")، والتي تسمح بالتراجع عن العمليات التي قد تؤثر على بنية المجموعة بأكملها أو التي تضيف أو تزيل مجموعات بيانات كاملة.

تاريخ

2004-2010: التطوير في شركة Sun Microsystems

في عام 1987، أعلنت شركة AT&T Corporation وشركة Sun عن تعاونهما في مشروع لدمج أكثر إصدارات يونكس شيوعًا في السوق في ذلك الوقت: Berkeley Software Distribution و UNIX System V و Xenix . أصبح هذا Unix System V Release 4 (SVR4). [11] تم إصدار المشروع تحت اسم Solaris ، والذي أصبح خليفة SunOS 4 (على الرغم من أن إصدارات SunOS 4.1.x الصغيرة كانت تسمى بأثر رجعي Solaris 1 ). [12]

تم تصميم ZFS وتنفيذه بواسطة فريق في Sun بقيادة Jeff Bonwick وBill Moore، [13] وMatthew Ahrens. تم الإعلان عنه في 14 سبتمبر 2004، [14] لكن التطوير بدأ في عام 2001. [15] تم دمج الكود المصدر لـ ZFS في الجذع الرئيسي لتطوير Solaris في 31 أكتوبر 2005 [16] وتم إصداره للمطورين كجزء من الإصدار 27 من OpenSolaris في 16 نوفمبر 2005. في يونيو 2006، أعلنت Sun أن ZFS تم تضمينه في تحديث 6/06 الرئيسي لـ Solaris 10. [ 17]

تم تطوير Solaris في الأصل كبرنامج احتكاري ، لكن شركة Sun Microsystems كانت من أوائل المؤيدين التجاريين للبرمجيات مفتوحة المصدر وفي يونيو 2005 أصدرت معظم قاعدة بيانات Solaris بموجب ترخيص CDDL وأسست مشروع OpenSolaris مفتوح المصدر . [18] في Solaris 10 6/06 ("U2")، أضافت شركة Sun نظام الملفات ZFS وقامت بتحديث ZFS بشكل متكرر بميزات جديدة خلال السنوات الخمس التالية. تم نقل ZFS إلى Linux و Mac OS X (استمر باسم MacZFS ) و FreeBSD بموجب ترخيص المصدر المفتوح هذا.

في وقت ما، قيل أن الاسم يرمز إلى "نظام ملفات زيتابايت"، [19] ولكن بحلول عام 2006، لم يعد الاسم يُعتبر اختصارًا. [20] يمكن لنظام ملفات ZFS تخزين ما يصل إلى 256 كوادريليون زيتابايت (ZB).

في سبتمبر 2007، رفعت شركة NetApp دعوى قضائية ضد شركة Sun، مدعية أن ZFS انتهك بعض براءات اختراع شركة NetApp في مجال تخطيط الملفات Write Anywhere . وفي أكتوبر من نفس العام، رفعت شركة Sun دعوى قضائية مضادة مدعية العكس. وانتهت الدعاوى القضائية في عام 2010 بتسوية غير معلنة. [21]

2010-حتى الآن: التطوير في Oracle، OpenZFS

بدأت الإصدارات المنقولة من ZFS في الظهور في عام 2005. وبعد استحواذ شركة Oracle على Sun في عام 2010، أصبحت نسخة Oracle من ZFS مغلقة المصدر، واستمر تطوير الإصدارات مفتوحة المصدر بشكل مستقل، بتنسيق من OpenZFS منذ عام 2013.

سمات

ملخص

تتضمن أمثلة الميزات الخاصة بنظام ZFS ما يلي:

  • مُصمم لتخزين البيانات على المدى الطويل، وأحجام مخزن بيانات غير محدودة مع فقدان صفر للبيانات، وقابلية تكوين عالية.
  • التحقق من صحة مجموع البيانات والبيانات الوصفية بشكل هرمي ، مما يضمن إمكانية التحقق من نظام التخزين بالكامل عند الاستخدام، والتأكد من تخزينه بشكل صحيح، أو إصلاحه في حالة تلفه. يتم تخزين مجموعات التحقق مع كتلة الأصل الخاصة بالكتلة ، وليس مع الكتلة نفسها. يتناقض هذا مع العديد من أنظمة الملفات حيث يتم تخزين مجموعات التحقق (إذا تم الاحتفاظ بها) مع البيانات بحيث إذا فقدت البيانات أو فسدت، فمن المحتمل أيضًا أن يكون مجموع التحقق مفقودًا أو غير صحيح.
  • يمكن تخزين عدد محدد من نسخ البيانات أو البيانات الوصفية، أو أنواع محددة من البيانات، لتحسين القدرة على استرداد الملفات والهياكل المهمة من تلف البيانات.
  • التراجع التلقائي عن التغييرات الأخيرة على نظام الملفات والبيانات، في بعض الظروف، في حالة حدوث خطأ أو عدم تناسق.
  • إصلاح ذاتي تلقائي وصامت (عادةً) لتناقضات البيانات وفشل الكتابة عند اكتشافها، وذلك لجميع الأخطاء التي تكون البيانات فيها قابلة لإعادة البناء. يمكن إعادة بناء البيانات باستخدام كل ما يلي: مجموعات التحقق من الأخطاء وتصحيحها المخزنة في كتلة الأصل لكل كتلة؛ نسخ متعددة من البيانات (بما في ذلك مجموعات التحقق) المحفوظة على القرص؛ نوايا الكتابة المسجلة على SLOG (ZIL) للكتابات التي كان من المفترض أن تحدث ولكنها لم تحدث (بعد انقطاع التيار الكهربائي)؛ بيانات التكافؤ من أقراص ومجلدات RAID/RAID-Z؛ نسخ من البيانات من الأقراص والمجلدات المنسوخة.
  • التعامل الأصلي مع مستويات RAID القياسية وتخطيطات RAID الإضافية لـ ZFS ("RAID-Z"). تقوم مستويات RAID-Z بتوزيع البيانات عبر الأقراص المطلوبة فقط، لتحقيق الكفاءة (تقوم العديد من أنظمة RAID بتوزيع البيانات بشكل عشوائي عبر جميع الأجهزة)، كما يسمح التحقق من صحة البيانات بإعادة بناء البيانات غير المتسقة أو التالفة بحيث يتم تقليلها إلى تلك الكتل التي بها عيوب؛
  • التعامل الأصلي مع أجهزة التخزين المتدرجة والتخزين المؤقت، والتي عادة ما تكون مهمة مرتبطة بالحجم. ولأن ZFS يفهم أيضًا نظام الملفات، فإنه يستطيع استخدام المعرفة المتعلقة بالملفات لإعلامه ودمجه وتحسين التعامل مع التخزين المتدرج الذي لا يستطيع جهاز منفصل القيام به؛
  • معالجة أصلية للقطات الفورية والنسخ الاحتياطي/ التكرار والتي يمكن أن تصبح فعّالة من خلال دمج معالجة المجلد والملف. يتم توفير الأدوات ذات الصلة على مستوى منخفض وتتطلب نصوصًا وبرامج خارجية للاستخدام.
  • ضغط البيانات الأصلية وإزالة التكرار ، على الرغم من أن الأخيرة تتم إلى حد كبير في ذاكرة الوصول العشوائي وتستهلك الكثير من الذاكرة.
  • إعادة بناء فعالة لمصفوفات RAID - غالبًا ما يتعين على وحدة تحكم RAID إعادة بناء القرص بالكامل، ولكن يمكن لنظام ZFS الجمع بين معرفة القرص والملف للحد من أي إعادة بناء للبيانات المفقودة أو التالفة بالفعل، مما يسرع عملية إعادة البناء بشكل كبير؛
  • لا يتأثر بتغيرات أجهزة RAID التي تؤثر على العديد من الأنظمة الأخرى. في العديد من الأنظمة، إذا تعطلت أجهزة RAID ذاتية الاحتواء مثل بطاقة RAID، أو تم نقل البيانات إلى نظام RAID آخر، فسوف يفتقر نظام الملفات إلى المعلومات التي كانت موجودة على أجهزة RAID الأصلية، والتي تعد ضرورية لإدارة البيانات على مجموعة RAID. وقد يؤدي هذا إلى فقدان كامل للبيانات ما لم يتم الحصول على أجهزة متطابقة تقريبًا واستخدامها كـ "حجر أساس". نظرًا لأن ZFS يدير RAID بنفسه، فيمكن نقل مجموعة ZFS إلى أجهزة أخرى، أو يمكن إعادة تثبيت نظام التشغيل، وسيتم التعرف على هياكل وبيانات RAID-Z ويمكن الوصول إليها على الفور بواسطة ZFS مرة أخرى.
  • القدرة على تحديد البيانات التي كان من الممكن العثور عليها في ذاكرة التخزين المؤقت ولكن تم التخلص منها مؤخرًا بدلاً من ذلك؛ وهذا يسمح لـ ZFS بإعادة تقييم قرارات التخزين المؤقت في ضوء الاستخدام اللاحق ويسهل مستويات عالية جدًا من إصابة ذاكرة التخزين المؤقت (معدلات إصابة ذاكرة التخزين المؤقت ZFS عادة ما تكون أكثر من 80٪)؛
  • يمكن استخدام استراتيجيات التخزين المؤقت البديلة للبيانات التي قد تتسبب بخلاف ذلك في تأخيرات في معالجة البيانات. على سبيل المثال، يمكن تحويل عمليات الكتابة المتزامنة القادرة على إبطاء نظام التخزين إلى عمليات كتابة غير متزامنة من خلال كتابتها في جهاز تخزين مؤقت سريع منفصل، يُعرف باسم SLOG (يُطلق عليه أحيانًا ZIL – ZFS Intent Log).
  • قابلة للضبط بدرجة عالية - يمكن تكوين العديد من المعلمات الداخلية للحصول على الأداء الوظيفي الأمثل.
  • يمكن استخدامه لمجموعات التوفر العالية والحوسبة، على الرغم من أنه غير مصمم بالكامل لهذا الاستخدام.

سلامة البيانات

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

أظهرت دراسة أجريت عام 1999 أن أيًا من أنظمة الملفات الرئيسية والمنتشرة آنذاك (مثل UFS أو Ext أو [22] XFS أو JFS أو NTFS ) أو RAID للأجهزة (التي تعاني من بعض المشكلات المتعلقة بسلامة البيانات ) لم توفر حماية كافية ضد مشاكل تلف البيانات. [23] [24] [25] [26] تشير الأبحاث الأولية إلى أن ZFS يحمي البيانات بشكل أفضل من الجهود السابقة. [27] [28] كما أنه أسرع من UFS [29] [30] ويمكن اعتباره بديلاً له.

داخل ZFS، يتم تحقيق سلامة البيانات باستخدام مجموع اختباري قائم على Fletcher أو تجزئة SHA-256 في جميع أنحاء شجرة نظام الملفات. [31] يتم جمع كل كتلة من البيانات ويتم حفظ قيمة المجموع الاختباري بعد ذلك في المؤشر إلى تلك الكتلة - بدلاً من الكتلة الفعلية نفسها. بعد ذلك، يتم جمع مؤشر الكتلة، مع حفظ القيمة في مؤشره . يستمر هذا الجمع الاختباري طوال الطريق إلى أعلى التسلسل الهرمي لبيانات نظام الملفات إلى العقدة الجذرية، والتي يتم جمعها أيضًا، وبالتالي إنشاء شجرة ميركل . [31] لا يمكن اكتشاف تلف البيانات أثناء الرحلة أو عمليات القراءة/الكتابة الوهمية (البيانات المكتوبة/المقروءة مجموع اختباري بشكل صحيح ولكنها في الواقع خاطئة) بواسطة معظم أنظمة الملفات لأنها تخزن المجموع الاختباري مع البيانات. يخزن ZFS مجموع الاختبار لكل كتلة في مؤشر الكتلة الأصلية الخاصة بها بحيث يتم التحقق من صحة المجموعة بالكامل ذاتيًا. [31]

عند الوصول إلى كتلة، بغض النظر عما إذا كانت بيانات أو بيانات وصفية، يتم حساب مجموعها الاختباري ومقارنتها بقيمة مجموعها الاختباري المخزن لما "يجب" أن تكون عليه. إذا تطابقت مجموعها الاختباري، يتم تمرير البيانات عبر مكدس البرمجة إلى العملية التي طلبت ذلك؛ إذا لم تتطابق القيم، فيمكن لـ ZFS معالجة البيانات إذا كانت مجموعة التخزين توفر تكرارًا للبيانات (مثل النسخ الداخلي )، على افتراض أن نسخة البيانات غير تالفة وبمجموعات اختبارية متطابقة. [32] من الممكن اختياريًا توفير تكرار إضافي داخل المجموعة من خلال تحديد copies=2 (أو copies=3 )، مما يعني أنه سيتم تخزين البيانات مرتين (أو ثلاث مرات) على القرص، مما يقلل فعليًا إلى النصف (أو، بالنسبة لـ copies=3 ، يقلل إلى الثلث) سعة تخزين القرص. [33] بالإضافة إلى ذلك، يتم تخزين بعض أنواع البيانات التي يستخدمها ZFS لإدارة المجموعة عدة مرات افتراضيًا من أجل السلامة حتى مع الإعداد الافتراضي copies=1.

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

إذا لم تكن هناك نسخ من البيانات التالفة، يضع ZFS المجموعة في حالة معيبة، [34] مما يمنع استخدامها في المستقبل ولا يوفر طرقًا موثقة لاستعادة محتويات المجموعة.

لا يتم التحقق من اتساق البيانات المحفوظة في الذاكرة، مثل البيانات المخزنة مؤقتًا في ARC، بشكل افتراضي، حيث من المتوقع أن يعمل ZFS على أجهزة عالية الجودة مع ذاكرة وصول عشوائي لتصحيح الأخطاء . ومع ذلك، فإن القدرة على التحقق من البيانات الموجودة في الذاكرة موجودة ويمكن تمكينها باستخدام "علامات التصحيح". [35]

RAID ("RAID-Z")

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

تجنب وحدات تحكم RAID للأجهزة

في حين يمكن لنظام ZFS العمل مع أجهزة RAID ، فإنه يعمل عادةً بكفاءة أكبر وبحماية أكبر للبيانات إذا كان لديه وصول خام إلى جميع أجهزة التخزين. يعتمد نظام ZFS على القرص للحصول على عرض صادق لتحديد اللحظة التي يتم فيها تأكيد كتابة البيانات بأمان ولديه العديد من الخوارزميات المصممة لتحسين استخدامه للتخزين المؤقت ، وتنظيف ذاكرة التخزين المؤقت ، ومعالجة القرص.

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

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

إذا كان من الضروري توصيل الأقراص من خلال RAID أو وحدة تحكم أخرى، فمن المستحسن تقليل كمية المعالجة التي تتم في وحدة التحكم باستخدام HBA (محول مضيف) عادي أو بطاقة توزيع بسيطة أو تكوين البطاقة في وضع JBOD (أي إيقاف تشغيل RAID ووظائف التخزين المؤقت)، للسماح بتوصيل الأجهزة مع الحد الأدنى من التغييرات في مسار الإدخال/الإخراج من ZFS إلى القرص. قد تتداخل بطاقة RAID في وضع JBOD إذا كانت تحتوي على ذاكرة تخزين مؤقتة أو، اعتمادًا على تصميمها، قد تفصل محركات الأقراص التي لا تستجيب في الوقت المناسب (كما حدث مع العديد من محركات الأقراص الصلبة الموفرة للطاقة والمخصصة للمستهلكين)، وبالتالي، قد تتطلب محركات الأقراص الممكّنة باستعادة الخطأ المحدود زمنيًا (TLER)/CCTL/ERC لمنع انقطاع المحرك، لذلك ليست كل البطاقات مناسبة حتى مع تعطيل وظائف RAID. [36]

نهج ZFS: RAID-Z والنسخ المتطابق

بدلاً من RAID المادي، يستخدم ZFS RAID "الناعم"، ويوفر RAID-Z ( يعتمد على التكافؤ مثل RAID 5 وما شابه) ونسخ القرص (مشابه لـ RAID 1 ). المخططات مرنة للغاية.

RAID-Z هو مخطط توزيع بيانات/تكافؤ مثل RAID-5 ، لكنه يستخدم عرض شريط ديناميكي: كل كتلة هي شريط RAID خاص بها، بغض النظر عن حجم الكتلة، مما يؤدي إلى أن تكون كل عملية كتابة RAID-Z عبارة عن كتابة شريطية كاملة. عند دمج هذا مع دلالات المعاملات النسخ عند الكتابة في ZFS، يتم التخلص من خطأ ثقب الكتابة . RAID-Z أسرع أيضًا من RAID 5 التقليدي لأنه لا يحتاج إلى تنفيذ تسلسل القراءة والتعديل والكتابة المعتاد . [37]

نظرًا لأن جميع الشرائط لها أحجام مختلفة، يتعين على إعادة بناء RAID-Z أن تمر عبر بيانات التعريف الخاصة بنظام الملفات لتحديد هندسة RAID-Z الفعلية. سيكون هذا مستحيلًا إذا كان نظام الملفات ومجموعة RAID منتجات منفصلة، ​​في حين يصبح ذلك ممكنًا عندما يكون هناك عرض متكامل للهيكل المنطقي والمادي للبيانات. يعني المرور عبر البيانات التعريفية أن ZFS يمكنه التحقق من صحة كل كتلة مقابل مجموعها الاختباري المكون من 256 بت أثناء مرورها، في حين لا تستطيع منتجات RAID التقليدية عادةً القيام بذلك. [37]

بالإضافة إلى التعامل مع حالات فشل القرص بالكامل، يمكن لـ RAID-Z أيضًا اكتشاف وتصحيح تلف البيانات الصامت ، مما يوفر "بيانات ذاتية الشفاء": عند قراءة كتلة RAID-Z، يقارنها ZFS بمجموعها الاختباري، وإذا لم ترد أقراص البيانات الإجابة الصحيحة، يقرأ ZFS التكافؤ ثم يحسب القرص الذي أعاد بيانات تالفة. ثم يقوم بإصلاح البيانات التالفة ويعيد البيانات الجيدة إلى مقدم الطلب. [37]

لا تتطلب تقنية RAID-Z والنسخ المتطابق أي أجهزة خاصة: فهي لا تحتاج إلى ذاكرة NVRAM لضمان الموثوقية، ولا تحتاج إلى تخزين مؤقت للكتابة لضمان الأداء الجيد أو حماية البيانات. مع تقنية RAID-Z، توفر تقنية ZFS تخزينًا سريعًا وموثوقًا به باستخدام أقراص رخيصة الثمن. [ ترويج؟ ] [37]

هناك خمسة أوضاع مختلفة لـ RAID-Z: التجريد (مشابه لـ RAID 0، لا يوفر أي تكرار)، RAID-Z1 (مشابه لـ RAID 5، يسمح بفشل قرص واحد)، RAID-Z2 (مشابه لـ RAID 6، يسمح بفشل قرصين)، RAID-Z3 (تكوين RAID 7 [a] ، يسمح بفشل ثلاثة أقراص)، والنسخ المتطابق (مشابه لـ RAID 1، يسمح بفشل جميع الأقراص باستثناء قرص واحد). [39]

نشأت الحاجة إلى RAID-Z3 في أوائل العقد الأول من القرن الحادي والعشرين مع انتشار محركات الأقراص ذات السعة التي تصل إلى عدة تيرابايتات. هذه الزيادة في السعة - دون زيادة مقابلة في سرعات الإنتاج - تعني أن إعادة بناء مجموعة بسبب فشل محرك الأقراص قد "تستغرق أسابيع أو أشهرًا بسهولة" لإكمالها. [38] خلال هذا الوقت، ستتعرض الأقراص القديمة في المجموعة للضغط بسبب عبء العمل الإضافي، مما قد يؤدي إلى تلف البيانات أو فشل محرك الأقراص. من خلال زيادة التكافؤ، يقلل RAID-Z3 من فرصة فقدان البيانات ببساطة عن طريق زيادة التكرار. [40]

إعادة التنظيف والتنظيف (مزامنة المصفوفة والتحقق من سلامتها)

لا يحتوي ZFS على أداة معادلة لـ fsck (أداة فحص وإصلاح البيانات القياسية لنظامي التشغيل Unix وLinux لأنظمة الملفات). [41] بدلاً من ذلك، يحتوي ZFS على وظيفة تنظيف مدمجة تقوم بفحص جميع البيانات بانتظام وإصلاح التلف الصامت والمشكلات الأخرى. بعض الاختلافات هي:

  • يجب تشغيل fsck على نظام ملفات غير متصل بالإنترنت، مما يعني أنه يجب فصل نظام الملفات ولا يمكن استخدامه أثناء الإصلاح، بينما تم تصميم scrub لاستخدامه على نظام ملفات مباشر مثبت، ولا يحتاج إلى فصل نظام ملفات ZFS عن الاتصال بالإنترنت.
  • عادةً ما يتحقق fsck فقط من البيانات الوصفية (مثل سجل المجلة) ولكنه لا يتحقق من البيانات نفسها مطلقًا. وهذا يعني أنه بعد fsck، قد لا تتطابق البيانات مع البيانات الأصلية المخزنة.
  • لا يمكن لبرنامج fsck دائمًا التحقق من صحة البيانات وإصلاحها عندما يتم تخزين مجموعات الاختبار مع البيانات (غالبًا ما تكون هذه هي الحال في العديد من أنظمة الملفات)، لأن مجموعات الاختبار قد تكون تالفة أو غير قابلة للقراءة أيضًا. يخزن ZFS دائمًا مجموعات الاختبار بشكل منفصل عن البيانات التي يتم التحقق منها، مما يحسن الموثوقية وقدرة Scrub على إصلاح وحدة التخزين. يخزن ZFS أيضًا نسخًا متعددة من البيانات - قد تحتوي البيانات الوصفية، على وجه الخصوص، على ما يصل إلى 4 أو 6 نسخ (نسخ متعددة لكل قرص ومرايا قرص متعددة لكل وحدة تخزين)، مما يحسن بشكل كبير من قدرة Scrub على اكتشاف وإصلاح الضرر الشامل لوحدة التخزين، مقارنةً بـ fsck.
  • يتحقق برنامج Scrub من كل شيء، بما في ذلك البيانات الوصفية والبيانات. ويمكن ملاحظة التأثير من خلال مقارنة أوقات فحص النظام بزمن فحص النظام - في بعض الأحيان يكتمل فحص النظام على RAID كبير في بضع دقائق، مما يعني أن البيانات الوصفية فقط هي التي تم فحصها. يستغرق فحص كل البيانات الوصفية والبيانات على RAID كبير عدة ساعات، وهذا هو بالضبط ما يفعله برنامج Scrub.
  • بينما يكتشف fsck الأخطاء ويحاول إصلاحها باستخدام بيانات نظام الملفات المتاحة، يعتمد scrub على التكرار للتعافي من المشكلات. بينما يعرض fsck إصلاح نظام الملفات مع فقدان جزئي للبيانات، يضعه scrub في حالة معيبة إذا لم يكن هناك تكرار. [34]

التوصية الرسمية من Sun/Oracle هي تنظيف أقراص مستوى المؤسسة مرة واحدة في الشهر، وأقراص السلع الرخيصة مرة واحدة في الأسبوع. [42] [43]

سعة

ZFS هو نظام ملفات 128 بت ، [44] [16] لذا يمكنه معالجة 1.84 × 10 19 مرة من البيانات أكثر من أنظمة 64 بت مثل Btrfs . تم تصميم الحدود القصوى لنظام ZFS لتكون كبيرة جدًا بحيث لا ينبغي مواجهتها عمليًا. على سبيل المثال، يتطلب ملء مجموعة zpool واحدة بالكامل بـ 2 128 بت من البيانات 3 × 10 24  تيرابايت من محركات الأقراص الصلبة. [45]

بعض الحدود النظرية في ZFS هي:

  • 16 إكسبي بايت (2 64 بايت): الحد الأقصى لحجم الملف الواحد
  • 2 48 : عدد الإدخالات في أي دليل فردي [46]
  • 16 إكسبي بايت: الحد الأقصى لحجم أي سمة
  • 2 56 : عدد سمات الملف (مقيد فعليًا بـ 2 48 لعدد الملفات في الدليل)
  • 256 كوادريليون زيبي بايت (2 128 بايت): الحد الأقصى لحجم أي مجموعة بيانات
  • 2 64 : عدد الأجهزة في أي مجموعة zpool
  • 2 64 : عدد أنظمة الملفات في مجموعة الملفات zpool
  • 2 64 : عدد مجموعات zpools في النظام

التشفير

مع Oracle Solaris، يتم تضمين قدرة التشفير في ZFS [47] في خط أنابيب الإدخال/الإخراج. أثناء عمليات الكتابة، قد يتم ضغط كتلة وتشفيرها وفحص مجموعها ثم إزالة التكرار، بهذا الترتيب. يتم تعيين سياسة التشفير على مستوى مجموعة البيانات عند إنشاء مجموعات البيانات (أنظمة الملفات أو ZVOLs). يمكن تغيير مفاتيح التغليف التي يوفرها المستخدم/المسؤول في أي وقت دون إيقاف تشغيل نظام الملفات. السلوك الافتراضي هو أن يتم توريث مفتاح التغليف بواسطة أي مجموعات بيانات فرعية. يتم إنشاء مفاتيح تشفير البيانات بشكل عشوائي في وقت إنشاء مجموعة البيانات. فقط مجموعات البيانات المنحدرة (اللقطات والاستنساخ) تشارك مفاتيح تشفير البيانات. [48] يتم توفير أمر للتبديل إلى مفتاح تشفير بيانات جديد للاستنساخ أو في أي وقت - وهذا لا يعيد تشفير البيانات الموجودة بالفعل، بل يستخدم بدلاً من ذلك آلية مفتاح رئيسي مشفرة.

اعتبارًا من عام 2019، تم أيضًا دمج ميزة التشفير بالكامل في OpenZFS 0.8.0 المتوفر لتوزيعات Debian وUbuntu Linux. [49]

كانت هناك تقارير قصصية من المستخدمين النهائيين عن حالات فشل عند استخدام تشفير ZFS الأصلي. لم يتم تحديد السبب الدقيق. [50] [51]

كفاءة القراءة والكتابة

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

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

تميل المساحة الحرة في ZFS إلى التفتت مع الاستخدام. لا يحتوي ZFS على آلية لإلغاء تجزئة المساحة الحرة. هناك تقارير غير مؤكدة من المستخدمين النهائيين عن انخفاض الأداء عندما يقترن تفتت المساحة الحرة العالية بالإفراط في استخدام مساحة القرص. [52] [53]


مميزات اخرى

أجهزة التخزين وقطع الغيار والحصص

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

لا يقتصر تكوين مجموعة التخزين على الأجهزة المتشابهة، بل يمكن أن تتكون من مجموعات غير متجانسة من الأجهزة، والتي يقوم نظام الملفات ZFS بتجميعها معًا بسلاسة، ثم توزيع المساحة على مجموعات البيانات (مثيلات نظام الملفات أو ZVOLs) حسب الحاجة. يمكن إضافة أنواع عشوائية من أجهزة التخزين إلى مجموعات موجودة لتوسيع حجمها. [54]

تتوفر سعة تخزين جميع برامج التطوير الافتراضية لجميع نسخ نظام الملفات في مجموعة zpool. ويمكن تعيين حصة للحد من مقدار المساحة التي يمكن لنسخة نظام الملفات أن تشغلها، ويمكن تعيين حجز لضمان توفر المساحة لنسخة نظام الملفات.

آليات التخزين المؤقت: ARC، L2ARC، مجموعات المعاملات، ZIL، SLOG، Special VDEV

يستخدم ZFS طبقات مختلفة من ذاكرة التخزين المؤقت للقرص لتسريع عمليات القراءة والكتابة. من الناحية المثالية، يجب تخزين جميع البيانات في ذاكرة الوصول العشوائي، ولكن هذا عادة ما يكون مكلفًا للغاية. لذلك، يتم تخزين البيانات تلقائيًا في تسلسل هرمي لتحسين الأداء مقابل التكلفة؛ [55] غالبًا ما تسمى هذه "مجموعات التخزين الهجينة". [56] سيتم تخزين البيانات التي يتم الوصول إليها بشكل متكرر في ذاكرة الوصول العشوائي، ويمكن تخزين البيانات التي يتم الوصول إليها بشكل أقل على وسائط أبطأ، مثل محركات الأقراص ذات الحالة الصلبة (SSDs). لا يتم تخزين البيانات التي لا يتم الوصول إليها كثيرًا وتترك على محركات الأقراص الصلبة البطيئة. إذا تمت قراءة البيانات القديمة فجأة كثيرًا، فسيقوم ZFS بنقلها تلقائيًا إلى محركات أقراص الحالة الصلبة أو إلى ذاكرة الوصول العشوائي.

تتضمن آليات التخزين المؤقت ZFS واحدة لكل من عمليات القراءة والكتابة، وفي كل حالة، يمكن أن يوجد مستويان من التخزين المؤقت، أحدهما في ذاكرة الكمبيوتر (RAM) والآخر على وحدة تخزين سريعة (عادةً محركات الأقراص ذات الحالة الصلبة (SSD))، بإجمالي أربعة ذاكرات تخزين مؤقتة.

  أين يتم تخزينها قراءة ذاكرة التخزين المؤقت كتابة ذاكرة التخزين المؤقت
ذاكرة التخزين المؤقت للمستوى الأول في ذاكرة الوصول العشوائي تُعرف باسم ARC ، وذلك بسبب استخدامها لمتغير من خوارزمية ذاكرة التخزين المؤقت البديلة التكيفية (ARC). سيتم استخدام ذاكرة الوصول العشوائي دائمًا للتخزين المؤقت، وبالتالي يكون هذا المستوى موجودًا دائمًا. تعني كفاءة خوارزمية ARC أنه لن تكون هناك حاجة للوصول إلى الأقراص غالبًا، بشرط أن يكون حجم ذاكرة التخزين المؤقت كبيرًا بدرجة كافية. إذا كانت ذاكرة الوصول العشوائي صغيرة جدًا، فلن يكون هناك أي ذاكرة تخزين مؤقتة على الإطلاق؛ في هذه الحالة، يحتاج ZFS دائمًا إلى الوصول إلى الأقراص الأساسية، مما يؤثر على الأداء بشكل كبير. يتم التعامل مع هذه المشكلة عن طريق "مجموعات المعاملات" - حيث يتم تجميع عمليات الكتابة على مدى فترة قصيرة (عادةً من 5 إلى 30 ثانية) حتى حد معين، حيث يتم كتابة كل مجموعة على القرص بشكل مثالي أثناء تجميع المجموعة التالية. وهذا يسمح بتنظيم عمليات الكتابة بشكل أكثر كفاءة للأقراص الأساسية مع خطر فقدان البيانات الطفيفة لأحدث المعاملات عند انقطاع التيار الكهربائي أو حدوث عطل في الأجهزة. وفي الممارسة العملية، يتم تجنب خطر فقدان الطاقة من خلال تسجيل عمليات الكتابة في ZFS ومن خلال مجموعة ذاكرة التخزين المؤقت للكتابة من المستوى الثاني SLOG/ZIL (انظر أدناه)، وبالتالي لن يتم فقد عمليات الكتابة إلا إذا حدث فشل في الكتابة في نفس الوقت الذي يحدث فيه فقدان كامل لمجموعة ذاكرة التخزين المؤقت للكتابة من المستوى الثاني SLOG، وعندئذٍ فقط عندما يتم ضبط الإعدادات المتعلقة بالكتابة المتزامنة واستخدام SLOG بطريقة تسمح بحدوث مثل هذا الموقف. وإذا تم استلام البيانات بشكل أسرع مما يمكن كتابتها، يتم إيقاف استلام البيانات مؤقتًا حتى تتمكن الأقراص من اللحاق بالركب.
ذاكرة التخزين المؤقت للمستوى الثاني وسجل النية على أجهزة التخزين السريعة (والتي يمكن إضافتها أو إزالتها من نظام "حي" دون انقطاع في الإصدارات الحالية من ZFS، على الرغم من عدم حدوث ذلك دائمًا في الإصدارات الأقدم) يُعرف باسم L2ARC ("Level 2 ARC")، وهو اختياري. سيخزن ZFS أكبر قدر ممكن من البيانات في L2ARC، والذي قد يصل إلى عشرات أو مئات الجيجابايت في كثير من الحالات. كما سيعمل L2ARC على تسريع إزالة التكرار بشكل كبير إذا كان من الممكن تخزين جدول إزالة التكرار بالكامل في L2ARC. قد يستغرق الأمر عدة ساعات لملء L2ARC بالكامل من الفراغ (قبل أن يقرر ZFS أي البيانات "ساخنة" ويجب تخزينها مؤقتًا). إذا فُقِد جهاز L2ARC، فستنتقل جميع القراءات إلى الأقراص مما يؤدي إلى إبطاء الأداء، ولكن لن يحدث أي شيء آخر (لن تُفقد أي بيانات). تُعرف هذه المصطلحات باسم SLOG أو ZIL ("سجل نوايا ZFS") - وغالبًا ما تُستخدم بشكل غير صحيح. يُعد SLOG (جهاز السجل الثانوي) ذاكرة تخزين مؤقتة مخصصة اختيارية على جهاز منفصل لتسجيل عمليات الكتابة في حالة حدوث مشكلة في النظام. إذا كان جهاز SLOG موجودًا، فسيتم استخدامه لسجل نوايا ZFS كسجل مستوى ثانٍ، وإذا لم يتم توفير جهاز ذاكرة تخزين مؤقت منفصل، فسيتم إنشاء ZIL على أجهزة التخزين الرئيسية بدلاً من ذلك. وبالتالي، يشير SLOG من الناحية الفنية إلى القرص المخصص الذي يتم تفريغ ZIL عليه، من أجل تسريع المجموعة. بالمعنى الدقيق للكلمة، لا يستخدم ZFS جهاز SLOG لتخزين عمليات الكتابة على القرص مؤقتًا. بل يستخدم SLOG لضمان التقاط عمليات الكتابة إلى وسيط تخزين دائم بأسرع ما يمكن، بحيث في حالة انقطاع الطاقة أو فشل الكتابة، لن يتم فقد أي بيانات تم الاعتراف بأنها مكتوبة. يسمح جهاز SLOG لنظام ZFS بتخزين عمليات الكتابة بسرعة والإبلاغ عنها بسرعة على أنها مكتوبة، حتى بالنسبة لأجهزة التخزين مثل محركات الأقراص الصلبة التي تكون أبطأ كثيرًا. في سياق النشاط الطبيعي، لا تتم الإشارة إلى SLOG أو قراءتها مطلقًا، ولا تعمل كذاكرة تخزين مؤقتة؛ الغرض منها هو حماية البيانات أثناء النقل خلال الثواني القليلة التي تستغرقها عملية التجميع و"الكتابة"، في حالة فشل الكتابة في النهاية. إذا سارت الأمور على ما يرام، فسيتم تحديث مجموعة التخزين في وقت ما خلال الثواني الخمس إلى الستين التالية، عندما يتم كتابة مجموعة المعاملات الحالية على القرص (انظر أعلاه)، وعند هذه النقطة سيتم تجاهل عمليات الكتابة المحفوظة على SLOG واستبدالها ببساطة. إذا فشلت عملية الكتابة في النهاية، أو تعرض النظام لعطل أو خلل يمنع كتابته، فيمكن لنظام ZFS تحديد جميع عمليات الكتابة التي أكد أنها كتبت، من خلال قراءة SLOG (الوقت الوحيد الذي تتم قراءته منه)، واستخدام هذا لإصلاح فقدان البيانات تمامًا.

يصبح هذا أمرًا بالغ الأهمية إذا حدث عدد كبير من عمليات الكتابة المتزامنة (مثل ESXi و NFS وبعض قواعد البيانات )، [57] حيث يتطلب العميل تأكيد الكتابة الناجحة قبل مواصلة نشاطه؛ يسمح SLOG لـ ZFS بتأكيد نجاح الكتابة بشكل أسرع بكثير مما لو كان عليه الكتابة إلى المتجر الرئيسي في كل مرة، دون المخاطرة التي تنطوي عليها تضليل العميل فيما يتعلق بحالة تخزين البيانات. إذا لم يكن هناك جهاز SLOG، فسيتم استخدام جزء من مجموعة البيانات الرئيسية لنفس الغرض، على الرغم من أن هذا أبطأ.

إذا تم فقد جهاز السجل نفسه، فمن الممكن أن يتم فقد أحدث عمليات الكتابة، وبالتالي يجب عمل نسخة طبق الأصل لجهاز السجل. في الإصدارات السابقة من ZFS، قد يؤدي فقد جهاز السجل إلى فقد مجموعة zpool بأكملها، على الرغم من أن هذا لم يعد هو الحال. لذلك، يجب على المرء ترقية ZFS إذا كان يخطط لاستخدام جهاز سجل منفصل.

يوجد أيضًا عدد من ذاكرات التخزين المؤقتة وتقسيمات ذاكرات التخزين المؤقتة والطوابير الأخرى داخل ZFS. على سبيل المثال، يحتوي كل VDEV على ذاكرة تخزين مؤقتة خاصة به للبيانات، ويتم تقسيم ذاكرة التخزين المؤقت ARC بين البيانات المخزنة بواسطة المستخدم والبيانات الوصفية المستخدمة بواسطة ZFS، مع التحكم في التوازن بينهما.

فئة VDEV الخاصة

في OpenZFS 0.8 والإصدارات الأحدث، من الممكن تكوين فئة VDEV خاصة لتخزين بيانات التعريف الخاصة بنظام الملفات بشكل تفضيلي، واختياريًا جدول إزالة التكرار للبيانات (DDT)، وكتل نظام الملفات الصغيرة. [58] يسمح هذا، على سبيل المثال، بإنشاء VDEV خاص على وحدة تخزين الحالة الصلبة السريعة لتخزين البيانات التعريفية، بينما يتم تخزين بيانات الملف العادية على أقراص دوارة. يؤدي هذا إلى تسريع العمليات التي تعتمد على البيانات التعريفية بشكل مكثف مثل عبور نظام الملفات، والتنظيف، وإعادة الصقل، دون تكلفة تخزين نظام الملفات بالكامل على وحدة تخزين الحالة الصلبة.

نموذج المعاملات النسخ عند الكتابة

يستخدم ZFS نموذج كائن معاملات النسخ عند الكتابة . تحتوي جميع مؤشرات الكتل داخل نظام الملفات على مجموع اختباري 256 بت أو تجزئة 256 بت (حاليًا خيار بين Fletcher-2 أو Fletcher-4 أو SHA-256 ) [59] للكتلة المستهدفة، والتي يتم التحقق منها عند قراءة الكتلة. لا يتم الكتابة فوق الكتل التي تحتوي على بيانات نشطة في مكانها أبدًا؛ بدلاً من ذلك، يتم تخصيص كتلة جديدة، وكتابة البيانات المعدلة عليها، ثم تتم قراءة أي كتل بيانات وصفية تشير إليها وإعادة تخصيصها وكتابتها على نحو مماثل. لتقليل النفقات العامة لهذه العملية، يتم تجميع التحديثات المتعددة في مجموعات معاملات، ويتم استخدام ذاكرة التخزين المؤقت للكتابة ZIL ( سجل النية ) عندما تكون دلالات الكتابة المتزامنة مطلوبة. يتم ترتيب الكتل في شجرة، وكذلك مجموعات الاختبار الخاصة بها (انظر مخطط توقيع ميركل ).

اللقطات والاستنساخات

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

يمكن أيضًا إنشاء لقطات قابلة للكتابة ("نسخ")، مما يؤدي إلى إنشاء نظامي ملفات مستقلين يتشاركان مجموعة من الكتل. مع إجراء تغييرات على أي من أنظمة الملفات المستنسخة، يتم إنشاء كتل بيانات جديدة لتعكس هذه التغييرات، ولكن تظل أي كتل غير متغيرة مشتركة، بغض النظر عن عدد النسخ الموجودة. هذا هو تنفيذ لمبدأ النسخ عند الكتابة .

إرسال واستقبال اللقطات

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

خطوط ديناميكية

إن التوزيع الديناميكي عبر جميع الأجهزة لتحقيق أقصى قدر من الإنتاجية يعني أنه مع إضافة أجهزة إضافية إلى مجموعة zpool، يتوسع عرض التوزيع تلقائيًا ليشملها؛ وبالتالي، يتم استخدام جميع الأقراص في مجموعة، مما يوازن بين حمل الكتابة عبرها. [60]

أحجام الكتل المتغيرة

يستخدم ZFS كتلًا ذات أحجام متغيرة، بحجم افتراضي يبلغ 128 كيلوبايت. تتيح الميزات المتاحة للمسؤول ضبط الحد الأقصى لحجم الكتلة المستخدم، حيث لا تعمل أحمال العمل المحددة بشكل جيد مع الكتل الكبيرة. إذا تم تمكين ضغط البيانات ، يتم استخدام أحجام كتلة متغيرة. إذا كان من الممكن ضغط كتلة لتناسب حجم كتلة أصغر، يتم استخدام الحجم الأصغر على القرص لاستخدام مساحة تخزين أقل وتحسين إنتاجية الإدخال والإخراج (على الرغم من زيادة استخدام وحدة المعالجة المركزية لعمليات الضغط وفك الضغط). [61]

إنشاء نظام ملفات خفيف الوزن

في ZFS، يكون التعامل مع نظام الملفات داخل مجموعة تخزين أسهل من التعامل مع الحجم داخل نظام ملفات تقليدي؛ فالوقت والجهد المطلوبين لإنشاء أو توسيع نظام ملفات ZFS أقرب إلى إنشاء دليل جديد منه إلى التعامل مع الحجم في بعض الأنظمة الأخرى. [ بحاجة لمصدر ]

الترابط التكيفي

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

لا يؤثر هذا على البيانات المخزنة؛ فكما هو معتاد في أنظمة POSIX ، تظهر الملفات للتطبيقات كمصفوفات بسيطة من البايتات، وبالتالي تظل التطبيقات التي تنشئ البيانات وتقرأها مسؤولة عن القيام بذلك بطريقة مستقلة عن ترتيب النظام الأساسي.

إزالة التكرار

تمت إضافة إمكانيات إزالة تكرار البيانات إلى مستودع مصدر ZFS في نهاية أكتوبر 2009، [62] وأصبحت حزم تطوير OpenSolaris ZFS ذات الصلة متاحة منذ 3 ديسمبر 2009 (الإصدار 128).

قد يتطلب الاستخدام الفعال لإزالة التكرار سعة ذاكرة وصول عشوائي كبيرة؛ تتراوح التوصيات بين 1 و5 جيجابايت من ذاكرة الوصول العشوائي لكل تيرابايت من التخزين. [63] [64] [65] يتم إجراء تقييم دقيق للذاكرة المطلوبة لإزالة التكرار من خلال الرجوع إلى عدد الكتل الفريدة في المجمع وعدد البايتات الموجودة على القرص وفي ذاكرة الوصول العشوائي ("النواة") المطلوبة لتخزين كل سجل - يتم الإبلاغ عن هذه الأرقام بواسطة أوامر مدمجة مثل zpoolو zdb. يمكن أن يؤدي عدم كفاية الذاكرة الفعلية أو نقص ذاكرة التخزين المؤقت ZFS إلى تعطل الذاكرة الافتراضية عند استخدام إزالة التكرار، مما قد يتسبب في انخفاض الأداء أو يؤدي إلى تجويع الذاكرة تمامًا. [ بحاجة لمصدر ] نظرًا لأن إزالة التكرار تحدث في وقت الكتابة، فهي أيضًا كثيفة الاستخدام لوحدة المعالجة المركزية ويمكن أن يؤدي هذا أيضًا إلى إبطاء النظام بشكل كبير.

يستخدم بائعو التخزين الآخرون إصدارات معدلة من ZFS لتحقيق نسب ضغط بيانات عالية جدًا . كان هناك مثالان في عام 2012 هما GreenBytes [66] وTegile. [67] في مايو 2014، اشترت شركة Oracle شركة GreenBytes لتقنية إزالة التكرار والتكرار الخاصة بنظام ZFS. [68]

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

قدرات إضافية

  • أولوية صريحة للإدخال والإخراج مع جدولة الموعد النهائي. [ بحاجة لمصدر ]
  • تم المطالبة بفرز وتجميع الإدخال/الإخراج الأمثل عالميًا. [ بحاجة لمصدر ]
  • تدفقات جلب مسبق متعددة مستقلة مع الكشف التلقائي عن الطول والخطوة. [ بحاجة لمصدر ]
  • عمليات الدليل المتوازية ذات الوقت الثابت. [ بحاجة لمصدر ]
  • التحقق الشامل من صحة البيانات، باستخدام نوع من " حقل سلامة البيانات "، مما يسمح باكتشاف تلف البيانات (واستعادتها إذا كان لديك تكرار في المجمع). يمكن استخدام اختيار من بين 3 تجزئات، مُحسَّنة للسرعة (فليتشر)، والتوحيد القياسي والأمان ( SHA256 )، وتجزئات مملحة ( سكيين ). [69]
  • ضغط نظام الملفات الشفاف. يدعم LZJB و gzip و [70] LZ4 و Zstd .
  • التنظيف الذكي وإعادة المزامنة . [71]
  • مشاركة التحميل واستخدام المساحة بين الأقراص في المجمع. [72]
  • كتل Ditto: تكرار البيانات القابلة للتكوين لكل نظام ملفات، مع عدم طلب أي نسخة إضافية أو نسخة واحدة أو نسختين لكل عملية كتابة لبيانات المستخدم، وبنفس العدد الأساسي من النسخ بالإضافة إلى نسخة واحدة أو نسختين للبيانات الوصفية (وفقًا لأهمية البيانات الوصفية). [73] إذا كان المجمع يحتوي على عدة أجهزة، يحاول ZFS التكرار عبر أجهزة مختلفة. كتل Ditto هي في الأساس حماية إضافية ضد القطاعات الفاسدة، وليس ضد فشل القرص الكامل. [74]
  • يعد تصميم ZFS (النسخ عند الكتابة + الكتل الفائقة) آمنًا عند استخدام الأقراص التي تم تمكين ذاكرة التخزين المؤقت للكتابة فيها، إذا كانت تحترم حواجز الكتابة. [ بحاجة لمصدر ] توفر هذه الميزة الأمان وتعزيز الأداء مقارنة ببعض أنظمة الملفات الأخرى. [ وفقًا لمن؟ ]
  • في Solaris، عندما تتم إضافة أقراص كاملة إلى مجموعة ZFS، يقوم ZFS تلقائيًا بتمكين ذاكرة التخزين المؤقتة للكتابة الخاصة بها. لا يتم ذلك عندما يدير ZFS شرائح منفصلة من القرص فقط، لأنه لا يعرف ما إذا كانت الشرائح الأخرى تُدار بواسطة أنظمة ملفات غير آمنة لذاكرة التخزين المؤقتة للكتابة، مثل UFS . [ بحاجة لمصدر ] يمكن لتطبيق FreeBSD التعامل مع عمليات مسح القرص للأقسام بفضل إطار عمل GEOM الخاص به ، وبالتالي لا يعاني من هذا القيد. [ بحاجة لمصدر ]
  • حدود الحصص لكل مستخدم ولكل مجموعة ولكل مشروع ولكل مجموعة بيانات. [75]
  • تشفير نظام الملفات منذ Solaris 11 Express، [76] وOpenZFS (ZoL) 0.8. [58] (على بعض الأنظمة الأخرى، يمكن لـ ZFS استخدام الأقراص المشفرة لتحقيق تأثير مماثل؛ يمكن استخدام GELI على FreeBSD بهذه الطريقة لإنشاء تخزين ZFS مشفر بالكامل).
  • يمكن استيراد المجمعات في وضع القراءة فقط.
  • من الممكن استرداد البيانات عن طريق التراجع عن المعاملات بالكامل في وقت استيراد zpool. [ بحاجة لمصدر ]
  • يمكن التقاط لقطات يدويًا أو تلقائيًا. يمكن عرض الإصدارات الأقدم من البيانات المخزنة التي تحتوي عليها كأنظمة ملفات كاملة للقراءة فقط. يمكن أيضًا عرضها كإصدارات تاريخية للملفات والمجلدات عند استخدامها مع CIFS (المعروف أيضًا باسم SMB أو Samba أو مشاركات الملفات)؛ يُعرف هذا باسم "الإصدارات السابقة" أو "نسخ الظل VSS" أو "سجل الملفات" على Windows أو AFP و"Apple Time Machine" على أجهزة Apple. [77]
  • يمكن وضع علامة على الأقراص باعتبارها "احتياطية". ويمكن ضبط مجموعة البيانات للتعامل تلقائيًا وشفافًا مع أخطاء الأقراص من خلال تنشيط قرص احتياطي والبدء في إعادة تخزين البيانات الموجودة على القرص المشتبه به عليه، عند الحاجة.

القيود

  • اعتبارًا من تحديث Solaris 10 11 وSolaris 11.2، لم يكن من الممكن تقليل عدد أجهزة التطوير الافتراضية عالية المستوى في مجموعة باستثناء قطع الغيار الساخنة والذاكرة المؤقتة وأجهزة السجل، ولا تقليل سعة المجموعة بأي شكل آخر. [78] قيل إن هذه الوظيفة كانت قيد التطوير في عام 2007. [79] التحسينات التي تسمح بتقليل أجهزة التطوير الافتراضية قيد التطوير في OpenZFS. [80] يتم دعم التقليص عبر الإنترنت عن طريق إزالة أجهزة التطوير الافتراضية عالية المستوى غير المكررة منذ إصدار Solaris 11.4 في أغسطس 2018 [81] وإصدار OpenZFS (ZoL) 0.8 في مايو 2019. [58]
  • اعتبارًا من عام 2008، لم يعد من الممكن إضافة قرص كعمود إلى RAID Z أو RAID Z2 أو RAID Z3 vdev. ومع ذلك، يمكن إنشاء RAID Z vdev جديد بدلاً من ذلك وإضافته إلى zpool. [82]
  • بعض تكوينات RAID المتداخلة التقليدية، مثل RAID 51 (مرآة لمجموعات RAID 5)، غير قابلة للتكوين في ZFS، بدون بعض أدوات الطرف الثالث. [83] لا يمكن تكوين Vdevs إلا من أقراص أو ملفات خام، وليس vdevs أخرى، باستخدام أوامر إدارة ZFS الافتراضية. [84] ومع ذلك، فإن مجموعة ZFS تنشئ فعليًا شريطًا (RAID 0) عبر vdevs الخاصة بها، وبالتالي فإن ما يعادل RAID 50 أو RAID 60 هو أمر شائع.
  • تتطلب إعادة تكوين عدد الأجهزة في vdev من المستوى الأعلى نسخ البيانات دون اتصال بالإنترنت، وتدمير المجموعة، وإعادة إنشاء المجموعة باستخدام تكوين vdev من المستوى الأعلى الجديد، باستثناء إضافة التكرار الإضافي إلى مرآة موجودة، والذي يمكن القيام به في أي وقت أو إذا كانت جميع vdevs من المستوى الأعلى عبارة عن مرايا ذات تكرار كافٍ، فيمكن استخدام أمر zpool split [85] لإزالة vdev من كل vdev من المستوى الأعلى في المجموعة، وإنشاء مجموعة ثانية ببيانات متطابقة.

استعادة البيانات

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

لقد نجح نظام ZFS الحديث في تحسين هذا الوضع بشكل كبير بمرور الوقت، ويستمر في القيام بذلك:

  • لم يعد إزالة أجهزة التخزين المؤقت أو فشلها المفاجئ يتسبب في فقدان المجموعة. (في أسوأ الأحوال، قد يؤدي فقدان ZIL إلى فقدان المعاملات الحديثة جدًا، ولكن ZIL لا يخزن عادةً أكثر من بضع ثوانٍ من المعاملات الحديثة. لا يؤثر فقدان ذاكرة التخزين المؤقت L2ARC على البيانات.)
  • إذا كانت المجموعة غير قابلة للتركيب، فستحاول الإصدارات الحديثة من ZFS تحديد أحدث نقطة ثابتة يمكن عندها استرداد المجموعة، على حساب فقدان بعض أحدث التغييرات التي طرأت على المحتويات. تعني النسخ عند الكتابة أن الإصدارات الأقدم من البيانات، بما في ذلك السجلات والبيانات الوصفية ذات المستوى الأعلى، قد تظل موجودة حتى لو تم استبدالها، وإذا كان الأمر كذلك، فيمكن إعادة المجموعة إلى حالة ثابتة بناءً عليها. كلما كانت البيانات أقدم، زادت احتمالية استبدال بعض الكتل على الأقل وأن بعض البيانات لن تكون قابلة للاسترداد، لذا فهناك حد في مرحلة ما لقدرة المجموعة على العودة إلى حالتها الأصلية.
  • بشكل غير رسمي، توجد أدوات لاستكشاف سبب عدم قدرة ZFS على تحميل مجموعة، وتوجيه المستخدم أو المطور فيما يتعلق بالتغييرات اليدوية المطلوبة لإجبار المجموعة على التحميل. تتضمن هذه استخدام zdb (تصحيح أخطاء ZFS) للعثور على نقطة صالحة قابلة للاستيراد في المجموعة، أو استخدام dtrace أو ما شابه ذلك لتحديد المشكلة التي تسبب فشل التحميل، أو تجاوز فحوصات الحالة يدويًا التي تتسبب في إلغاء عملية التحميل، والسماح بتحميل المجموعة التالفة.
  • اعتبارًا من مارس 2018 ، يتم طرح مجموعة من الأساليب المحسنة بشكل كبير تدريجيًا داخل OpenZFS. وتشمل هذه: [86]
  • إعادة هيكلة الكود، وتوفير معلومات تشخيصية وتصحيحية أكثر تفصيلاً حول حالات فشل التثبيت، لتبسيط تشخيص وإصلاح مشكلات المجموعة الفاسدة؛
  • القدرة على الثقة أو عدم الثقة في تكوين المجموعة المخزنة. وهذا قوي بشكل خاص، لأنه يسمح بتثبيت المجموعة حتى في حالة فقدان أو خلل في أجهزة التطوير الافتراضية من المستوى الأعلى، عندما تكون البيانات من المستوى الأعلى مشكوك فيها، كما يسمح أيضًا بالرجوع إلى ما بعد تغيير تكوين المجموعة إذا كان هذا التغيير مرتبطًا بالمشكلة. بمجرد تثبيت المجموعة الفاسدة، يمكن نسخ الملفات القابلة للقراءة من أجل الأمان، وقد يتبين أنه يمكن إعادة بناء البيانات حتى في حالة وجود أجهزة تطوير افتراضية مفقودة، وذلك باستخدام نسخ مخزنة في مكان آخر في المجموعة.
  • القدرة على إصلاح الموقف حيث تم إزالة القرص المطلوب في مجموعة واحدة عن طريق الخطأ وإضافته إلى مجموعة مختلفة، مما تسبب في فقدان البيانات الوصفية المرتبطة بالمجموعة الأولى، والتي أصبحت غير قابلة للقراءة.

OpenZFS وZFS

أوقفت شركة Oracle Corporation التطوير العام لكل من ZFS وOpenSolaris بعد استحواذها على Sun في عام 2010. قام بعض المطورين بتقسيم الإصدار العام الأخير من OpenSolaris إلى مشروع Illumos. نظرًا للمزايا المهمة الموجودة في ZFS، فقد تم نقله إلى العديد من المنصات المختلفة بميزات وأوامر مختلفة. لتنسيق جهود التطوير وتجنب التجزئة، تم تأسيس OpenZFS في عام 2013.

وفقًا لما ذكره مات أهرينز، أحد المهندسين المعماريين الرئيسيين لنظام ZFS، تم استبدال أكثر من 50% من كود OpenSolaris ZFS الأصلي في OpenZFS بمساهمات المجتمع اعتبارًا من عام 2019، مما يجعل "Oracle ZFS" و"OpenZFS" غير متوافقين سياسيًا وتكنولوجيًا. [87]

المنتجات التجارية والمفتوحة المصدر

  • 2008: قامت شركة Sun بشحن مجموعة من أجهزة التخزين من سلسلة 7000 المستندة إلى ZFS. [88]
  • 2013: قامت شركة Oracle بشحن سلسلة ZS3 من الملفات المستندة إلى ZFS واستحوذت على المركز الأول في معيار SPC-2 بواحد منها. [89]
  • 2013: قامت شركة iXsystems بشحن أجهزة NAS تعتمد على ZFS تسمى FreeNAS (والتي تسمى الآن TrueNAS CORE)، لأجهزة SOHO وأجهزة TrueNAS للمؤسسات. [90] [91]
  • 2014: قامت شركة Netgear بشحن مجموعة من أجهزة NAS المستندة إلى ZFS والتي تسمى ReadyDATA ، والمصممة للاستخدام في المؤسسات. [92]
  • 2015: أعلنت rsync.net عن منصة تخزين سحابية تسمح للعملاء بتجهيز مجموعة Zpool الخاصة بهم واستيراد وتصدير البيانات باستخدام zfs send وzfs Receive. [93] [94]
  • 2020: بدأت شركة iXsystems تطوير برنامج متقارب قائم على ZFS يسمى TrueNAS SCALE، للمكاتب الصغيرة والمنزلية و TrueNAS للمؤسسات. [91]

شركة أوراكل، المصدر المغلق، والتفرع (منذ عام 2010)

في يناير 2010، استحوذت شركة أوراكل على شركة صن مايكروسيستمز، وتوقفت بسرعة عن توزيع أوبن سولاريس ونموذج تطوير المصدر المفتوح. [95] [96] في أغسطس 2010، توقفت شركة أوراكل عن توفير التحديثات العامة لرمز المصدر لمستودع نظام التشغيل/الشبكات سولاريس، مما أدى فعليًا إلى تحويل سولاريس 11 مرة أخرى إلى نظام تشغيل خاص مغلق المصدر . [97]

استجابةً للمشهد المتغير لـ Solaris و OpenSolaris، تم إطلاق مشروع illumos عبر ندوة عبر الإنترنت [98] يوم الخميس 3 أغسطس 2010، كجهد مجتمعي لبعض مهندسي Solaris الأساسيين لمواصلة تطوير الإصدار مفتوح المصدر من Solaris، واستكمال المصدر المفتوح لتلك الأجزاء التي لم يتم فتحها بالفعل بواسطة Sun. [99] تم تأسيس illumos كمؤسسة، مؤسسة Illumos، المسجلة في ولاية كاليفورنيا كجمعية تجارية 501 (c) 6. ذكرت الخطة الأصلية صراحةً أن illumos لن يكون توزيعًا أو شوكة. ومع ذلك، بعد أن أعلنت شركة Oracle عن إيقاف OpenSolaris، تم وضع خطط لشوكة الإصدار النهائي من Solaris ON، مما يسمح لـ illumos بالتطور إلى نظام تشغيل خاص به. [100] كجزء من OpenSolaris، كان إصدار مفتوح المصدر من ZFS جزءًا لا يتجزأ من illumos.

تم استخدام ZFS على نطاق واسع في العديد من المنصات، بالإضافة إلى Solaris. لذلك، في عام 2013، تم نقل تنسيق أعمال التطوير على الإصدار مفتوح المصدر من ZFS إلى مشروع شامل، OpenZFS . يسمح إطار عمل OpenZFS لأي أطراف مهتمة بتطوير قاعدة بيانات ZFS الأساسية بشكل تعاوني، مع الحفاظ بشكل فردي على أي كود إضافي محدد يتطلبه ZFS للعمل والتكامل داخل أنظمتهم الخاصة.

تاريخ الإصدار

أسطورة:
الإصدار القديم
أحدث إصدار مستقر من FOSS
رقم إصدار نظام الملفات ZFS تاريخ الافراج عنه تغييرات كبيرة
1 OpenSolaris Nevada [101] الإصدار 36 الإصدار الأول
2 أوبن سولاريس نيفادا b69 إدخالات الدليل المحسنة. على وجه الخصوص، تقوم إدخالات الدليل الآن بتخزين نوع الكائن. على سبيل المثال، الملف، الدليل، الأنبوب المسمى، وما إلى ذلك، بالإضافة إلى رقم الكائن.
3 أوبن سولاريس نيفادا b77 دعم مشاركة أنظمة ملفات ZFS عبر SMB . دعم عدم حساسية الأحرف الكبيرة والصغيرة. دعم سمات النظام. دعم مكافحة الفيروسات المتكاملة.
4 أوبن سولاريس نيفادا b114 الخصائص: userquota، groupquota، userused وgroupused
5 أوبن سولاريس نيفادا b137 سمات النظام؛ الروابط الرمزية الآن لها نوع كائن خاص بها
رقم إصدار مجموعة ZFS تاريخ الافراج عنه تغييرات كبيرة
1 OpenSolaris نيفادا [101] b36 الإصدار الأول
2 أوبن سولاريس نيفادا b38 كتل ديتو
3 أوبن سولاريس نيفادا b42 قطع غيار ساخنة، RAID-Z مزدوج التكافؤ (raidz2)، تحسين محاسبة RAID-Z
4 أوبن سولاريس نيفادا b62 تاريخ zpool
5 أوبن سولاريس نيفادا b62 ضغط gzip لمجموعات البيانات ZFS
6 أوبن سولاريس نيفادا b62 خاصية تجمع "bootfs"
7 أوبن سولاريس نيفادا b68 ZIL: يضيف القدرة على تحديد جهاز أو أجهزة سجل نوايا منفصلة
8 أوبن سولاريس نيفادا b69 القدرة على تفويض المهام الإدارية الخاصة بـ zfs(1M) للمستخدمين العاديين
9 أوبن سولاريس نيفادا b77 دعم خادم CIFS وحصص مجموعة البيانات
10 أوبن سولاريس نيفادا b77 يمكن إضافة الأجهزة إلى مجموعة تخزين باعتبارها "أجهزة تخزين مؤقت"
11 أوبن سولاريس نيفادا b94 تحسين أداء فرك/تلميع zpool
12 أوبن سولاريس نيفادا b96 خصائص اللقطة
13 أوبن سولاريس نيفادا b98 الخصائص: usedbysnapshots، usedbychildren، usedbyrefreservation، وusedbydataset
14 أوبن سولاريس نيفادا b103 دعم خاصية passthrough-x aclinherit
15 أوبن سولاريس نيفادا b114 الخصائص: userquota، groupquota، usuerused وgroupused؛ مطلوب أيضًا FS v4
16 أوبن سولاريس نيفادا b116 دعم خاصية STMF
17 أوبن سولاريس نيفادا b120 RAID-Z ثلاثي التكافؤ
18 أوبن سولاريس نيفادا b121 لقطة ZFS تحتفظ
19 أوبن سولاريس نيفادا b125 إزالة جهاز سجل ZFS
20 أوبن سولاريس نيفادا b128 خوارزمية ضغط zle المطلوبة لدعم خصائص إزالة التكرار في ZFS في إصدار مجموعة ZFS 21، والتي تم إصدارها في نفس الوقت
21 أوبن سولاريس نيفادا b128 إزالة التكرار
22 أوبن سولاريس نيفادا b128 zfs يستقبل الخصائص
23 أوبن سولاريس نيفادا b135 زيل نحيف
24 أوبن سولاريس نيفادا b137 سمات النظام. أصبحت الروابط الرمزية الآن نوعًا خاصًا بها من الكائنات. كما تتطلب أيضًا نظام الملفات الإصدار 5.
25 أوبن سولاريس نيفادا b140 تحسين إحصائيات تنظيف المسبح وإعادة تلميعه
26 أوبن سولاريس نيفادا b141 تم تحسين أداء حذف اللقطات
27 أوبن سولاريس نيفادا b145 تم تحسين أداء إنشاء اللقطات الفورية (اللقطات الفورية المتكررة بشكل خاص)
28 أوبن سولاريس نيفادا b147 استبدال أجهزة افتراضية متعددة

ملاحظة: كان الاسم الرمزي لإصدار Solaris الذي كان قيد التطوير بواسطة Sun منذ إصدار Solaris 10 في عام 2005 هو "Nevada"، وكان مشتقًا من قاعدة بيانات OpenSolaris . "Solaris Nevada" هو الاسم الرمزي لنظام التشغيل Solaris من الجيل التالي الذي سيخلف Solaris 10 في النهاية، ثم تم سحب هذا الرمز الجديد على التوالي إلى إصدارات OpenSolaris "Nevada" الجديدة. [101] تم إيقاف OpenSolaris الآن وتم تقسيم OpenIndiana منه. [102] [103] تم نشر الإصدار النهائي (b134) من OpenSolaris بواسطة Oracle (2010-11-12) كمسار ترقية إلى Solaris 11 Express .

دعم نظام التشغيل

قائمة أنظمة التشغيل والتوزيعات والإضافات التي تدعم ZFS، وإصدار zpool الذي يدعمه، وإصدار Solaris الذي يعتمد عليه (إن وجد):

نظام التشغيل نسخة Zpool إصدار Sun/Oracle # تعليقات
أوراكل سولاريس 11.4 49 11.4.51 (11.4 SRU 51) [104]
أوراكل سولاريس 11.3 37 0.5.11-0.175.3.1.0.5.0
أوراكل سولاريس 10 1/13 (U11) 32
أوراكل سولاريس 11.2 35 0.5.11-0.175.2.0.0.42.0
أوراكل سولاريس 11 2011.11 34 ب175
أوراكل سولاريس إكسبريس 11 2010.11 31 ب151أ مرخصة للاختبار فقط
أوبن سولاريس 2009.06 14 ب111ب
OpenSolaris (التطوير الأخير) 22 ب134
أوبن إنديانا 5000 ب147 توزيع يعتمد على illumos ؛ يخلق تضاربًا في الأسماء من خلال تسمية رمز البناء الخاص به "b151a"
نيكسينتا كور 3.0.1 26 ب134+ أرض مستخدمي جنو
مجتمع NexentaStor 3.0.1 26 ب134+ حتى 18 تيرابايت، مسؤول الويب
مجتمع NexentaStor 3.1.0 28 ب134+ أرض مستخدمي جنو
مجتمع NexentaStor 4.0 5000 ب134+ حتى 18 تيرابايت، مسؤول الويب
نيكسينتاستور إنتربرايز 28 ب134+ ليس مجانيًا، مسؤول الويب
GNU/kFreeBSD "Squeeze" (غير مدعوم) 14 يتطلب الحزمة "zfsutils"
GNU/kFreeBSD "Wheezy-9" (غير مدعوم) 28 يتطلب الحزمة "zfsutils"
فري بي إس دي 5000
zfs-fuse 0.7.2 23 عانى من مشاكل في الأداء؛ توقف عن العمل
ZFS على Linux 0.6.5.8 5000 يحتوي الإصدار المرشح 0.6.0 على طبقة POSIX
نظام ZFS من KQ Infotech على Linux 28 غير صالح للاستخدام؛ تم دمج الكود في ZFS المدعوم من LLNL على Linux
بيلينكس 0.8b1 14 ب111 توزيع أقراص مضغوطة حية صغيرة الحجم؛ كانت تعتمد في السابق على OpenSolaris
شيليكس 0.7.2 28 ب147 توزيع أقراص مضغوطة حية صغيرة الحجم؛ مثل SchilliX-ON 0.8.0 المستند إلى OpenSolaris
StormOS "تحية" توزيع كان يعتمد في السابق على Nexenta Core 2.0+، Debian Linux؛ ثم حل محله Dyson OS
جاريس توزيع Sola ris الياباني ؛ يعتمد في السابق على OpenSolaris
ميلاكس 0.5 20 ب128أ توزيع أقراص مضغوطة حية صغيرة الحجم؛ كانت تعتمد في السابق على OpenSolaris
فريناس 8.0.2 / 8.2 15
فريناس 8.3.0 28 مبني على FreeBSD 8.3
برنامج FreeNAS 9.1.0+ 5000 مبني على FreeBSD 9.1+
زيجماناس 11.4.0.4/12.2.0.4 5000 مبني على FreeBSD 11.4/12.2
كورونا 4.5.0 22 ب134 كيدي
EON NAS (الإصدار 0.6) 22 ب130 NAS مضمن
EON NAS (الإصدار 1.0beta) 28 ب151أ NAS مضمن
ناپ-يت 28/5000 إيلوموس/سولاريس جهاز تخزين؛ OpenIndiana (Hipster)، OmniOS، Solaris 11، Linux (إدارة ZFS)
أومني أو إس سي إي 28/5000 فرع illumos-OmniOS توزيع خادم تخزين مستقر/LTS بسيط يعتمد على Illumos، مدفوعًا بالمجتمع
نظام التشغيل الذكي 28/5000 إيلوموس ب151+ توزيع مباشر بسيط يعتمد على Illumos (تمهيد USB/CD)؛ استخدام السحابة والمشرف الافتراضي (KVM)
ماك أو إس 10.5، 10.6، 10.7، 10.8، 10.9 5000 عبر MacZFS؛ تم استبداله بنظام OpenZFS على نظام التشغيل OS X
ماك 10.6، 10.7، 10.8 28 عبر ZEVO؛ تم استبداله بـ OpenZFS على OS X
نت بي إس دي 22
منتصف الليلBSD 6
بروكسموكس في إي 5000 دعم أصلي منذ عام 2014، pve.proxmox.com/wiki/ZFS_on_Linux
أوبونتو لينكس 16.04 LTS+ 5000 الدعم الأصلي عبر الوحدة الثنائية القابلة للتثبيت، wiki.ubuntu.com/ZFS
ZFSGuru 10.1.100 5000

انظر أيضا

ملحوظات

  1. ^ في حين أن RAID 7 ليس مستوى RAID قياسيًا، فقد تم اقتراحه كمصطلح شامل لأي تكوين RAID >3 تكافؤ [38]

مراجع

  1. ^ "ما هو ZFS؟". دليل إدارة Oracle Solaris ZFS . Oracle. مؤرشف من الأصل في 4 مارس 2016. تم الاسترجاع في 29 ديسمبر 2015 .
  2. ^ "ترخيص ZFS على Linux". GitHub . تم الاسترجاع في 17 مايو 2020 .
  3. ^ "إطلاق مشروع OpenZFS". LWN.net . 17 سبتمبر 2013. مؤرشف من الأصل في 4 أكتوبر 2013. تم الاسترجاع في 1 أكتوبر 2013 .
  4. ^ "إعلان OpenZFS". OpenZFS . 17 سبتمبر 2013. مؤرشف من الأصل في 2 أبريل 2018. تم الاسترجاع في 19 سبتمبر 2013 .
  5. ^ open-zfs.org /History Archived December 24, 2013, at the Wayback Machine "OpenZFS هو خليفة مفتوح المصدر حقًا لمشروع ZFS [...] تأثيرات الشوكة (منذ 2010 حتى الآن)"
  6. ^ Sean Michael Kerner (18 سبتمبر 2013). "LinuxCon: OpenZFS moves Open Source Storage Forward". infostor.com. مؤرشف من الأصل في 14 مارس 2014. تم الاسترجاع في 9 أكتوبر 2013 .
  7. ^ "إطلاق مشروع OpenZFS". LWN.net . 17 سبتمبر 2013. مؤرشف من الأصل في 11 أكتوبر 2016. تم الاسترجاع 1 أكتوبر 2013 .
  8. ^ "OpenZFS – Communities co-operating on ZFS code and features". freebsdnews.net. 23 سبتمبر 2013. مؤرشف من الأصل في 14 أكتوبر 2013. تم الاسترجاع في 14 مارس 2014 .
  9. ^ "الأسئلة الشائعة حول نظام Starline ZFS". Starline . تم الاسترجاع في 20 يوليو 2024 .
  10. ^ ab "19.4.zfs Administration". www.freebsd.org . مؤرشف من الأصل في 23 فبراير 2017 . تم الاسترجاع في 22 فبراير 2017 .
  11. ^ سالوس، بيتر (1994). ربع قرن من يونكس . أديسون ويسلي. ص 199-200. ISBN 0-201-54777-5.
  12. ^ "ما هو نظام التشغيل SunOS ونظام التشغيل Solaris؟". قاعدة المعرفة . خدمات تكنولوجيا جامعة إنديانا. 20 مايو 2013. تم الاسترجاع في 10 نوفمبر 2014 .
  13. ^ براون، ديفيد. "محادثة مع جيف بونويك وبيل مور". قائمة انتظار ACM . رابطة آلات الحوسبة. مؤرشف من الأصل في 16 يوليو 2011. تم الاسترجاع في 17 نوفمبر 2015 .
  14. ^ "ZFS: الكلمة الأخيرة في أنظمة الملفات". Sun Microsystems. 14 سبتمبر 2004. مؤرشف من الأصل في 28 أبريل 2006. تم الاسترجاع في 30 أبريل 2006 .
  15. ^ ماثيو أهرينز (1 نوفمبر 2011). "ZFS 10 year anniversary". مؤرشف من الأصل في 28 يونيو 2016. تم الاسترجاع في 24 يوليو 2012 .
  16. ^ ab Bonwick, Jeff (31 أكتوبر 2005). "ZFS: الكلمة الأخيرة في أنظمة الملفات". blogs.oracle.com . مؤرشف من الأصل في 19 يونيو 2013 . تم الاسترجاع في 22 يونيو 2013 .
  17. ^ "صن تحتفل بالذكرى السنوية الأولى الناجحة لـ OpenSolaris". صن مايكروسيستمز. 20 يونيو 2006. مؤرشف من الأصل في 28 سبتمبر 2008. تم الاسترجاع في 30 أبريل 2018 .
  18. ^ مايكل سينجر (25 يناير 2005). "Sun Cracks Open Solaris". InternetNews.com . تم الاسترجاع في 12 أبريل 2010 .
  19. ^ "ZFS FAQ at OpenSolaris.org". Sun Microsystems. مؤرشف من الأصل في 15 مايو 2011. تم الاسترجاع في 18 مايو 2011. كانت بادئة SI الأكبر التي أعجبتنا هي "zetta" (كان "yotta" خارج الحسبان)
  20. ^ جيف بونويك (3 مايو 2006). "أنت تقول زيتا، وأنا أقول زيتا". مدونة جيف بونويك . مؤرشف من الأصل في 23 فبراير 2017. تم الاسترجاع في 21 أبريل 2017. لذا قررنا أخيرًا إلغاء الاسم إلى ZFS، الذي لا يرمز لأي شيء .
  21. ^ "Oracle and NetApp refuse ZFS lawsuits". theregister.co.uk. 9 سبتمبر 2010. مؤرشف من الأصل في 9 سبتمبر 2017. تم الاسترجاع في 24 ديسمبر 2013 .
  22. ^ تم نسخ بنية البيانات الوصفية لنظام الملفات الممتد (Ext) من UFS. "Rémy Card (Interview, April 1998)". April Association. 19 أبريل 1999. مؤرشف من الأصل في 4 فبراير 2012. تم الاسترجاع في 8 فبراير 2012 .(بالفرنسية)
  23. ^ Vijayan Prabhakaran (2006). "IRON FILE SYSTEMS" (PDF) . دكتوراه في علوم الكمبيوتر . جامعة ويسكونسن ماديسون. مؤرشف من الأصل (PDF) في 29 أبريل 2011. تم الاسترجاع في 9 يونيو 2012 .
  24. ^ "Parity Lost and Parity Regained". مؤرشف من الأصل في 15 يونيو 2010. تم الاسترجاع في 29 نوفمبر 2010 .
  25. ^ "تحليل تلف البيانات في حزمة التخزين" (PDF) . مؤرشف من الأصل (PDF) في 15 يونيو 2010 . تم الاسترجاع في 29 نوفمبر 2010 .
  26. ^ "تأثير تلف القرص على أنظمة إدارة قواعد البيانات مفتوحة المصدر" (PDF) . مؤرشف من الأصل (PDF) في 15 يونيو 2010. تم الاسترجاع في 29 نوفمبر 2010 .
  27. ^ كاداف، عاصم؛ راجيموالي، أبيشيك. "تحليل موثوقية ZFS" (PDF) . مؤرشف من الأصل (PDF) في 21 سبتمبر 2013. تم الاسترجاع في 19 سبتمبر 2013 .
  28. ^ Yupu Zhang؛ Abhishek Rajimwale؛ Andrea Arpaci-Dusseau ؛ Remzi H. Arpaci-Dusseau (2010). "سلامة البيانات من البداية إلى النهاية لأنظمة الملفات: دراسة حالة ZFS" (PDF) . مؤتمر USENIX حول تقنيات الملفات والتخزين . CiteSeerX 10.1.1.154.3979 . S2CID  5722163. Wikidata  Q111972797 . تم الاسترجاع في 6 ديسمبر 2010 . 
  29. ^ لارابيل، مايكل. "مقارنة بين ZFS وUFS على FreeBSD وEXT4 وBtrfs على Linux". Phoronix Media 2012. مؤرشف من الأصل في 29 نوفمبر 2016. تم الاسترجاع في 21 نوفمبر 2012 .
  30. ^ لارابيل، مايكل. "هل يستطيع نظام تشغيل DragonFlyBSD's HAMMER التنافس مع Btrfs وZFS؟". Phoronix Media 2012. مؤرشف من الأصل في 29 نوفمبر 2016. تم الاسترجاع في 21 نوفمبر 2012 .
  31. ^ abc Bonwick, Jeff (8 ديسمبر 2005). "ZFS End-to-End Data Integrity". blogs.oracle.com . مؤرشف من الأصل في 3 أبريل 2012 . تم الاسترجاع في 19 سبتمبر 2013 .
  32. ^ كوك، تيم (16 نوفمبر 2009). "إظهار قدرة ZFS على الشفاء الذاتي". blogs.oracle.com . مؤرشف من الأصل في 12 أغسطس 2011. تم الاسترجاع في 1 فبراير 2015 .
  33. ^ رانش، ريتشارد (4 مايو 2007). "ZFS، والنسخ، وحماية البيانات". blogs.oracle.com . مؤرشف من الأصل في 18 أغسطس 2016 . تم الاسترجاع في 2 فبراير 2015 .
  34. ^ ab "zpoolconcepts.7 — OpenZFS documentation". openzfs.github.io . تم الاسترجاع في 5 أبريل 2023 .
  35. ^ "ZFS Without Tears: Using ZFS without ECC memory". www.csparks.com . ديسمبر 2015. مؤرشف من الأصل في 13 يناير 2021 . تم الاسترجاع في 16 يونيو 2020 .
  36. ^ wdc.custhelp.com. "الفرق بين محركات أقراص إصدار سطح المكتب وإصدار RAID (Enterprise)". مؤرشف من الأصل في 5 يناير 2015. تم الاسترجاع في 8 سبتمبر 2011 .
  37. ^ abcd Bonwick, Jeff (17 نوفمبر 2005). "RAID-Z". مدونة جيف بونويك . مدونات أوراكل . مؤرشف من الأصل في 16 ديسمبر 2014. تم الاسترجاع في 1 فبراير 2015 .
  38. ^ ab Leventhal, Adam (17 ديسمبر 2009). "Triple-Parity RAID and Beyond". Queue . 7 (11): 30. doi : 10.1145/1661785.1670144 .
  39. ^ "ZFS Raidz Performance, Capacity and integrity". calomel.org . مؤرشف من الأصل في 27 نوفمبر 2017 . تم الاسترجاع في 23 يونيو 2017 .
  40. ^ "لماذا يتوقف RAID 6 عن العمل في عام 2019". ZDNet . 22 فبراير 2010. مؤرشف من الأصل في 31 أكتوبر 2014. تم الاسترجاع في 26 أكتوبر 2014 .
  41. ^ "لا يوجد معادل لأداة fsck لنظام ZFS. كانت هذه الأداة تخدم تقليديًا غرضين، إصلاح نظام الملفات والتحقق من صحة نظام الملفات." "التحقق من سلامة نظام ملفات ZFS". Oracle. مؤرشف من الأصل في 31 يناير 2013. تم الاسترجاع في 25 نوفمبر 2012 .
  42. ^ "ZFS Scrubs". freenas.org. مؤرشف من الأصل في 27 نوفمبر 2012. تم الاسترجاع في 25 نوفمبر 2012 .
  43. ^ "يجب عليك أيضًا إجراء عملية تنظيف قبل استبدال الأجهزة أو تقليل التكرار المؤقت لمجموعة الأجهزة للتأكد من أن جميع الأجهزة تعمل حاليًا." "دليل أفضل ممارسات ZFS". solarisinternals.com. مؤرشف من الأصل في 5 سبتمبر 2015. تم الاسترجاع في 25 نوفمبر 2012 .
  44. ^ جيف بونويك. "التخزين 128 بت: هل أنت مرتفع؟". oracle.com . مؤرشف من الأصل في 29 مايو 2015. تم الاسترجاع في 29 مايو 2015 .
  45. ^ "ZFS: Boils the Ocean, Consumes the Moon (Dave Brillhart's Blog)". مؤرشف من الأصل في 8 ديسمبر 2015. تم الاسترجاع في 19 ديسمبر 2015 .
  46. ^ "دليل إدارة ZFS الخاص بـSolaris". Oracle Corporation. مؤرشف من الأصل في 13 يناير 2021. تم الاسترجاع في 11 فبراير 2011 .
  47. ^ "تشفير أنظمة ملفات ZFS". مؤرشف من الأصل في 23 يونيو 2011. تم الاسترجاع في 2 مايو 2011 .
  48. ^ "Having my secure cake and Cloning it too (aka Encryption + Dedup with ZFS)". مؤرشف من الأصل في 29 مايو 2013. تم الاسترجاع في 9 أكتوبر 2012 .
  49. ^ "ZFS – Debian Wiki". wiki.debian.org . مؤرشف من الأصل في 8 سبتمبر 2019 . تم الاسترجاع في 10 ديسمبر 2019 .
  50. ^ "اقتراح: النظر في إضافة تحذيرات ضد استخدام تشفير zfs الأصلي مع الإرسال/الاستقبال في الإنتاج". Github . Github . تم الاسترجاع في 15 أغسطس 2024 .
  51. ^ "PSA: ZFS لديه خطأ في تلف البيانات عند استخدام التشفير الأصلي والإرسال/الاستقبال". Reddit . Reddit . تم الاسترجاع في 15 أغسطس 2024 .
  52. ^ "تجزئة ZFS: حلول طويلة الأمد". Github . Github . تم الاسترجاع في 15 أغسطس 2024 .
  53. ^ "ما هي أفضل الممارسات للحفاظ على نظام الملفات ZFS من التفتت الشديد". Lawrence Systems . Lawrence Systems . تم الاسترجاع في 15 أغسطس 2024 .
  54. ^ "نظام Solaris ZFS يتيح مجموعات تخزين هجينة - يحطم الحواجز الاقتصادية وحواجز الأداء" (PDF) . Sun.com. 7 سبتمبر 2010. مؤرشف من الأصل (PDF) في 17 أكتوبر 2011. تم الاسترجاع في 4 نوفمبر 2011 .
  55. ^ جريج، بريندان. "ZFS L2ARC". مدونة بريندان . Dtrace.org. مؤرشف من الأصل في 6 نوفمبر 2011. تم الاسترجاع في 5 أكتوبر 2012 .
  56. ^ جريج، بريندان (8 أكتوبر 2009). "مجموعة التخزين الهجينة: السرعات القصوى". مدونة بريندان . Dtrace.org. مؤرشف من الأصل في 5 أبريل 2016. تم الاسترجاع في 15 أغسطس 2017 .
  57. ^ "ضبط أداء Solaris ZFS: الكتابة المتزامنة وZIL". Constantin.glez.de. 20 يوليو 2010. مؤرشف من الأصل في 23 يونيو 2012. تم الاسترجاع في 5 أكتوبر 2012 .
  58. ^ abc "إصدار zfs-0.8.0". GitHub . OpenZFS. 23 مايو 2019. تم الاسترجاع في 3 يوليو 2021 .
  59. ^ "ZFS On-Disk Specification" (PDF) . Sun Microsystems, Inc. 2006. مؤرشف من الأصل (PDF) في 30 ديسمبر 2008.انظر القسم 2.4.
  60. ^ "RAIDZ — OpenZFS documentation". openzfs.github.io . تم الاسترجاع في 9 فبراير 2023 .
  61. ^ Eric Sproul (21 مايو 2009). "ZFS Nuts and Bolts". slideshare.net. ص 30-31. مؤرشف من الأصل في 22 يونيو 2014. تم الاسترجاع في 8 يونيو 2014 .
  62. ^ "ZFS Deduplication". blogs.oracle.com . مؤرشف من الأصل في 24 ديسمبر 2019 . تم الاسترجاع في 25 نوفمبر 2019 .
  63. ^ جاري سيمز (4 يناير 2012). "إنشاء وحدة تخزين مرفقة بالشبكة تعتمد على نظام الملفات ZFS باستخدام FreeNAS 8". تدريب TrainSignal . TrainSignal, Inc. مؤرشف من الأصل (المدونة) في 7 مايو 2012 . تم الاسترجاع في 9 يونيو 2012 .
  64. ^ Ray Van Dolson (مايو 2011). "[zfs-discuss] ملخص: متطلبات ذاكرة إزالة التكرار". قائمة بريدية zfs-discuss. مؤرشف من الأصل في 25 أبريل 2012.
  65. ^ "ZFSTuningGuide". مؤرشف من الأصل في 16 يناير 2012. تم الاسترجاع في 3 يناير 2012 .
  66. ^ كريس ميلور (12 أكتوبر 2012). "GreenBytes brandishes full-fat clone VDI pumper". The Register . مؤرشف من الأصل في 24 مارس 2013 . تم الاسترجاع في 29 أغسطس 2013 .
  67. ^ كريس ميلور (1 يونيو 2012). "الوافد الجديد يخرج من صندوقه، ويخطط لبيعه بثمن بخس لجميع القادمين". السجل . مؤرشف من الأصل في 12 أغسطس 2013. تم الاسترجاع في 29 أغسطس 2013 .
  68. ^ كريس ميلور (11 ديسمبر 2014). "إزالة التكرار، إزالة التكرار... إزالة التكرار، إزالة التكرار، إزالة التكرار: أوراكل تصقل الماس الخاص بنظام الملفات المضغوطة". The Register . مؤرشف من الأصل في 7 يوليو 2017 . تم الاسترجاع في 17 ديسمبر 2014 .
  69. ^ "Checksums and Their Use in ZFS". github.com . 2 سبتمبر 2018. مؤرشف من الأصل في 19 يوليو 2019 . تم الاسترجاع 11 يوليو 2019 .
  70. ^ "دليل إدارة نظام الملفات ZFS من Solaris". الفصل 6 إدارة أنظمة الملفات ZFS . مؤرشف من الأصل في 5 فبراير 2011. تم الاسترجاع في 17 مارس 2009 .
  71. ^ "Smokin' Mirrors". blogs.oracle.com . 2 مايو 2006. مؤرشف من الأصل في 16 ديسمبر 2011. تم الاسترجاع في 13 فبراير 2012 .
  72. ^ "ZFS Block Allocation". مدونة جيف بونويك . 4 نوفمبر 2006. مؤرشف من الأصل في 2 نوفمبر 2012. تم الاسترجاع في 23 فبراير 2007 .
  73. ^ "Ditto Blocks — The Amazing Tape Repellent". Flippin' off bits Weblog . 12 مايو 2006. مؤرشف من الأصل في 26 مايو 2013. تم الاسترجاع في 1 مارس 2007 .
  74. ^ "إضافة أقراص جديدة وسلوك الحظر". مؤرشف من الأصل في 23 أغسطس 2011. تم الاسترجاع في 19 أكتوبر 2009 .
  75. ^ "OpenSolaris.org". Sun Microsystems. مؤرشف من الأصل في 8 مايو 2009. تم الاسترجاع في 22 مايو 2009 .
  76. ^ "ما الجديد في Solaris 11 Express 2010.11" (PDF) . Oracle. مؤرشف من الأصل (PDF) في 16 نوفمبر 2010 . تم الاسترجاع في 17 نوفمبر 2010 .
  77. ^ "10. المشاركة — دليل مستخدم FreeNAS 9.3 جدول المحتويات". doc.freenas.org . مؤرشف من الأصل في 7 يناير 2017 . تم الاسترجاع في 23 فبراير 2017 .
  78. ^ "معرف الخطأ 4852783: تقليل سعة المجمع". مشروع OpenSolaris. مؤرشف من الأصل في 29 يونيو 2009. تم الاسترجاع في 28 مارس 2009 .
  79. ^ Goebbels, Mario (19 أبريل 2007). "إزالة vdevs بشكل دائم من مجموعة". zfs-discuss (قائمة بريدية).[ رابط ميت دائم ] رابط الأرشيف محفوظ في 13 يناير 2021، على موقع Wayback Machine
  80. ^ معلومات كريس سيبنمان حول إزالة vdev في المستقبل أرشيف 11 أغسطس 2016، على موقع Wayback Machine ، جامعة تورنتو، مدونة، اقتباس: إعلان تويتر غير الرسمي بواسطة أليكس ريس أرشيف 11 أغسطس 2016، على موقع Wayback Machine
  81. ^ "ميزات إدارة البيانات – ما الجديد في Oracle® Solaris 11.4". مؤرشف من الأصل في 24 سبتمبر 2019. تم الاسترجاع في 9 أكتوبر 2019 .
  82. ^ "Expand-O-Matic RAID Z". Adam Leventhal. 7 أبريل 2008. مؤرشف من الأصل في 28 ديسمبر 2011. تم الاسترجاع في 16 أبريل 2012 .
  83. ^ "ZFS Toy". SourceForge.net . تم الاسترجاع في 12 أبريل 2022 .
  84. ^ "zpoolconcepts(7)". وثائق OpenZFS . OpenZFS. 2 يونيو 2021. تم الاسترجاع في 12 أبريل 2021. لا يمكن تعشيش الأجهزة الافتراضية، لذا لا يمكن لجهاز المرآة أو Raiz الافتراضي أن يحتوي إلا على ملفات أو أقراص. لا يُسمح بمرآة المرايا (أو مجموعات أخرى).
  85. ^ "zpool(1M)". Download.oracle.com. 11 يونيو 2010. مؤرشف من الأصل في 13 يناير 2021. تم الاسترجاع في 4 نوفمبر 2011 .
  86. ^ "استعادة بيانات ZFS بسرعة فائقة". مؤرشف من الأصل في 29 نوفمبر 2018. تم الاسترجاع في 29 نوفمبر 2018 .
  87. ^ "ZFS وOpenZFS". iXSystems . تم الاسترجاع في 18 مايو 2020 .
  88. ^ "Sun rolls out its own storage appliances". techworld.com.au. 11 نوفمبر 2008. مؤرشف من الأصل في 13 نوفمبر 2013. تم الاسترجاع في 13 نوفمبر 2013 .
  89. ^ كريس ميلور (2 أكتوبر 2013). "Oracle muscle way into seat atop the benchmark with hefty ZFS filer". theregister.co.uk. مؤرشف من الأصل في 7 يوليو 2017. تم الاسترجاع في 7 يوليو 2014 .
  90. ^ "Unified ZFS Storage Appliance built in Silicon Valley by iXsystem". ixsystems.com. مؤرشف من الأصل في 3 يوليو 2014. تم الاسترجاع في 7 يوليو 2014 .
  91. ^ "TrueNAS 12 & TrueNAS SCALE أصبحا متاحين رسميًا!". ixsystems.com . تم الاسترجاع في 2 يناير 2021 .
  92. ^ "ReadyDATA 516 – Unified Network Storage" (PDF) . netgear.com. مؤرشف من الأصل (PDF) في 15 يوليو 2014. تم الاسترجاع في 7 يوليو 2014 .
  93. ^ جيم سالتر (17 ديسمبر 2015). "rsync.net: أصبح تكرار ZFS إلى السحابة متاحًا أخيرًا—وهو سريع". arstechnica.com. مؤرشف من الأصل في 22 أغسطس 2017. تم الاسترجاع في 21 أغسطس 2017 .
  94. ^ rsync.net, Inc. "التخزين السحابي مع إرسال واستقبال ZFS عبر SSH". rsync.net. مؤرشف من الأصل في 21 يوليو 2017. تم الاسترجاع في 21 أغسطس 2017 .
  95. ^ ستيفن ستاليون / أوراكل (13 أغسطس 2010). "تحديث حول SXCE". اتجاهات تحطيم الأصنام. مؤرشف من الأصل في 9 نوفمبر 2020. تم الاسترجاع في 30 أبريل 2018 .
  96. ^ Alasdair Lumsden. "OpenSolaris canceled, to be Replacement with Solaris 11 Express". osol-discuss (Mailing list). مؤرشف من الأصل في 16 أغسطس 2010. تم الاسترجاع في 24 نوفمبر 2014 .
  97. ^ لا يزال Solaris مفتوحًا إلى حد ما، لكن توزيع OpenSolaris ميت محفوظ في 5 سبتمبر 2017، على موقع Wayback Machine على Ars Technica بواسطة Ryan Paul (16 أغسطس 2010)
  98. ^ جاريت ديمور (3 أغسطس 2010). "Illumos - الأمل والنور ينبعان من جديد - تقديم جاريت ديمور" (PDF) . illumos.org . تم الاسترجاع في 3 أغسطس 2010 .
  99. ^ "إلى أين تتجه شركة OpenSolaris؟ Illumos تتولى زمام الأمور". مؤرشف من الأصل في 26 سبتمبر 2015.
  100. ^ جاريت ديمور (13 أغسطس 2010). "قد تكون اليد مجبرة" . تم الاسترجاع في 14 نوفمبر 2013 .
  101. ^ abc "أثناء سيطرة Sun Microsystems، كانت هناك لقطات نصف شهرية لنظام التشغيل Solaris Nevada (الاسم الرمزي لنظام التشغيل Solaris من الجيل التالي الذي سيخلف Solaris 10 في النهاية) وتم سحب هذا الكود الجديد بعد ذلك إلى لقطات معاينة جديدة لنظام التشغيل OpenSolaris متوفرة على Genunix.org. تستند الإصدارات المستقرة من OpenSolaris إلى [ كذا ] إصدارات Nevada هذه." Larabel, Michael. "يبدو أن Oracle ستقف وراء OpenSolaris". Phoronix Media. مؤرشفة من الأصل في 29 نوفمبر 2016. تم الاسترجاع في 21 نوفمبر 2012 .
  102. ^ Ljubuncic, Igor (23 مايو 2011). "OpenIndiana — there's still hope". DistroWatch . مؤرشف من الأصل في 27 أكتوبر 2012 . تم الاسترجاع في 21 نوفمبر 2012 .
  103. ^ "مرحبًا بكم في مشروع OpenIndiana!". مشروع OpenIndiana. 10 سبتمبر 2010. مؤرشف من الأصل في 27 نوفمبر 2012. تم الاسترجاع في 14 سبتمبر 2010 .
  104. ^ "إصدارات مجموعة ZFS". Oracle Corporation. 2022. مؤرشف من الأصل في 21 ديسمبر 2022. تم الاسترجاع 1 يناير 2023 .

فهرس

  • واتانابي، سكوت (23 نوفمبر 2009). أساسيات نظام الملفات Solaris ZFS (الطبعة الأولى). برنتيس هول . ص 256. رقم ISBN 978-0-13-700010-4. تم أرشفة النسخة الأصلية في 1 أكتوبر 2012.
  • Fork Yeah! The Rise and Development of Illumos - عرض شرائح يغطي الكثير من تاريخ Solaris، وقرار Sun بالمصدر المفتوح، وإنشاء ZFS، والأحداث التي تسببت في إغلاق المصدر وتشعبه بعد استحواذ Oracle عليه.
  • تم إنشاء أفضل نظام ملفات سحابي قبل وجود السحابة (تم أرشفته في 15 ديسمبر 2018)
  • مقارنة بين النسخ المتطابق لـ SVM والنسخ المتطابق لـ ZFS
  • توزيع تخزين EON ZFS (NAS)
  • سلامة البيانات الشاملة لأنظمة الملفات: دراسة حالة ZFS
  • ZFS – نظام الملفات Zettabyte (تم أرشفته في 28 فبراير 2013)
  • ZFS وRAID-Z: نظام Über-FS؟
  • ZFS: الكلمة الأخيرة في أنظمة الملفات، بقلم جيف بونويك وبيل مور (تم أرشفته في 29 أغسطس 2017)
  • تصور سجل نوايا ZFS (ZIL)، أبريل 2013، بقلم آرون توبونس
  • مميزات illumos بما في ذلك OpenZFS
    • صفحة الويكي السابقة مع المزيد من الروابط: البدء باستخدام ZFS، 15 سبتمبر 2014 (تم أرشفته في 30 ديسمبر 2018)، جزء من وثائق illumos
Retrieved from "https://en.wikipedia.org/w/index.php?title=ZFS&oldid=1249561713"
Original text
Rate this translation
Your feedback will be used to help improve Google Translate