فقدان البتات و النسخ الآني الذري: نظرة داخل الجيل المقبل من أنظمة الملفات ( ZFS و Btrfs )

تأليف: جيم سالتر ، ترجمة شركة سبعة للتقنية، مراجعة فهد السعيدي

سننظر إلى الميزات العظيمة لنظام ZFS وBtrfs ولماذا سنحتاج لها.

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

هل يبدو الموضوع نظرياً أكثر مما يجب ليلفت انتباهك؟ لنتحدث إذاً عن "bitrot" فقدان البتات، المدمر الصامت للبيانات على الأقراص والأشرطة. ففي كل مرة، وبشكل سنوي، تتغير قمة بت واحدة هنا أو هناك. وإذا كان لديك محرك فيه خلل أو سلك تالف فهنالك العديد من البتات ستتغير قيمتها. فقدان البتات أمر حقيقي ويؤثر عليك بأشد مما تظن، تلك الصورة بامتداد JPEG والتي تشوهت من المنتصف بغرابة، هذا من عمل فقدان البتات، التسجيل الصوتي بامتدادmp3 والذي أخافك بصوت صفير مفاجئ وأخذت بالتساؤل ما إذا كان دائما يفعل ذلك؟ لا لم يكن يفعل ذلك، لُم فقدان البتات. الفيديو الذي بزاويته يوجد مربع أخضر وتظهر بعد ثوان ألوان قوس قزح قبل أن تصفى الشاشة من جديد؟ إنه من عمل فقدان البتات.

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

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

ما يمكنه أن يحمي بياناتك هو الجيل المقبل من أنظمة الملفات.

لننظر إلى الرسم البياني، هنا صورة لابني فن والتي أسميها " نشوء الشرير"، أحب هذه الصورة جدا وسأحزن لفقدانها ولهذا قمت بتخزينها في الجيل المقبل من أنظمة الملفات مع التكرار، لكن ماذا لو لم أفعل ذلك؟

كاختبار، قمت بتثبيت آلة افتراضية بستة أقراص، واحد يحتوي على نظام التشغيل واثنان أعّدت كمرآة بسيطة لريد1 والثلاثة المتبقية أٌعدت ب ريد 5 التقليدي. قمت بحفظ صورة فن على كلي القرصين من نوع ريد 1 والقائمة التقليدية ريد 5 ثم قمت بإغلاق النظام وغيّرت قيمة بت واحدة (من 0 إلى 1) في ملف الصورة ذات الامتداد jpg والمخزن في القائمة، وكانت هذه النتيجة:

 

الصورة الأصلية

الصورة المعطوبة على RAID5

الصورة المعطوبة على btrfs-raid1

 

قائمة ريد5 لم تلاحظ أو لم تهتم بالبت المتغير في صورة فن مثل أي قرص اعتيادي، بينما نظام الجيل المقبل من ريد1 قام بالملاحظة على الفور وصحح العطب، النتائج واضحة جدا، إذا كنت تهتم لبياناتك إذا فأنت تحتاج للجيل المقبل من أنظمة الملفات، هنا سنقوم باختبار نوعان من أنظمة الملفات: ZFS القديم والنوع الجديد btrfs.

ما هو الجيل المقبل من أنظمة الملفات على أية حال؟

"الجيل المقبل" هو شعار يتم تداوله من خلال مطويات الإعلانات في مواقف السيارات، لكن في هذه الحالة، هذا الشعار يعني شيئا أهم. أُعرّف " الجيل" من أنظمة الملفات كمجموعة تستخدم خاصية قاتلة لا تستخدمها الأجيال السابقة لكن كل الأجيال المستقبلية ستفعل. لنأخذ جولة سريعة لتاريخ هذه الأنظمة لنقارن بين الأجيال السابقة والحالية.

جيل 0: لا يوجد أي نظام، فقط سيل عشوائي من البيانات، مثل البطاقات المختومة والبيانات على الأشرطة الصوتية وبطاقات الروم 2600 لأتاري.

جيل 1: نظام وصول عشوائي، هنا نجد ملفات عديدة على جهاز واحد ولكن بدون مجلد أو بيانات توضيحية، مثل أبل، دوس ولكن ليس برو-دوس.

جيل 2: ظهور بوادر الترتيب (أي المجلدات) حينما أصبحت الأجهزة قادرة على تحمل مئات الملفات وبات ضروريا الحصول على تنظيم أفضل، نحن نقصد TRS-DOS و Apple c ProDOS وMS-DOS FAT/FAT32

جيل 3: جيل البيانات التوضيحية و الملكية وأذونات الوصول والى آخره. حينما ارتفع عدد المستخدمين للأجهزة، بات من المهم التحكم في الوصول لهذه الأجهزة، هذا يتضمن أي تي اند تي يونيكس AT&T UNIX، و Netware وأوائل NTFS.

الجيل 4: تدوين التغيرات! هذه هي الخاصية القاتلة التي تُعرف كل الأجيال الحالية والمستقبلية (ext4 و NTFS المعاصرة، UFS2) وكل ما يخطر ببالك من أمثلة. تدوين التغيرات يحمي نظام الملفات من وصوله إلى حالة غير مستقرة في حالة حدوث حالة انهيار مما يعني أن هنالك احتمالية أقل لخسارة بياناتك أو حتى من خسارة قرصك بالكامل في حالة فقدان الطاقة أو انهيار النواة نفسها.

 

إذا تقبلت تعريفي، إذا يكون المعنى الحالي لمصطلح " الجيل المقبل" هو الجيل الخامس ويُعرّف بأنه المجموعة الكاملة من الخواص: إدارة الحجم المضمنة، واختبار المجموع لكل كتلة، والتصحيح الذاتي للقوائم المتكررة واللقطات الألية للنسخ الآني، والتكرار غير المتزامن والقابلية للتوسع في المستقبل.

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

برر جيلك

 

أول اعتراض يمكن أن تعترضه هو أن تعريف الجيل بهذا الشكل سيجعل منه إشارة لخدمة اللقطات في NTFS أو مدير الحجم المنطقي في لينكس (LVM) , كلاهما يستطيع أخذ صورة من نظم الملفات المرتبطة بها. على أية حال، هذه اللقطات لا يمكنها التكرار بشكل تزايدي، أي أن تخزين الملفات لاستعادتها لاحقا بحجم واحد تيرابايت سيتطلب منك المرور على واحد تيرابايت في كل مرة (نظام الملفات UFS2 الخاص بنظام FreeBSD يوفر أيضا إمكانية أخذ اللقطات بشكل محدود).

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

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

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

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

 

ZFS، أكبر ما في الجيل

أحد الأدلة على أن مميزات: اللقطات، إدارة الحجم، التحقق من المجموع، التصليح آلي، التناسخ والتعدد هي مجموعة مميزات الجيل القادم من نظم إدارة الملفات أن نظام btrfs ليس نظام الملفات الأول الذي طبق هذه المميزات كاملة. نظام ZFS ( المصنوع من قبل صن مايكروسستم قبل تملك اوراكل لها) كان قد سبقه في السوق [ أطلق عام 2005م ].

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

سنقوم بمقارنة بين btrfs و ZFS من الآن فصاعدا ، كلا منهما لديه مميزاته و مساوئه ، سواء بشكل مستقل أو بالمقارنة.

ميزات الجيل القادم

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

 

لقطات النسخ الآني الذرية Atomic COW snapshots

إن لقطات النسخ الآني الذرية - و التي هي ببساطة أكثر ميزة يثير اسمها ضحكا في أي نظام ملفات- هي عبارة عن صورة كاملة لنظام الملفات بالوقت التي تم أخذها فيه مهما كان ما يُدار وقتها، أي إذا أخذت لقطة للنظام الساعة ٨:١٣ و ٣٢ ثانية مساءا في تاريخ ١٩ ديسمير ٢٠١٣ ، هذه اللقطة ستحتوي على كل بت موجود في نظام الملفات تماما كما كانت في نفس التاريخ و الوقت بدون أي حالات خاصة ، هذا سيساعد أي بنية عالية النشاط مثل قواعد البيانات على الثبات ، طالما أن قواعد البيانات تستخدم التدوين ( و إذا لم تستخدم ، قم بالترقية الآن! ) ستكون التدوينات متزامنة و ثابتة في اللقطات ، يمكن لأي عملية غير مكتملة أن تُعاد لتكتمل عوضا عن ترك قاعدة البيانات في حالة غير ثابتة.

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

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

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

نظام التحقق لكل كتلة

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

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

بالمقابل، مع كل كتلة بيانات تُكتب، يقوم btrfs بكتابة أيضا قيمة التحقق للكتلة ومع كل كتلة بيانات تُقرأ يقومbtrfs بقراءة قيمة التحقق ومطابقة الكتلة معها ، هذا يسمح لنظام الملفات ولك أيضا بمعرفة ما إذا كانت البيانات معطوبة في الحال.

القوائم ذاتية الإصلاح المتكررة

كما أوضحنا في مقدمة المقالة، نسخة صورة ابني في قائمة من btrfs ريد ١ تعرضت للعطب بتغيير قيمة بت واحدة، كما حصل أيضا للنسخة في قائمة ريد ٥، لكن قائمة btrfs لاحظت العطب وصححته بشكل مباشر حالما طلبت قراءة الصورة.

سجل نواة النظام يحكي القصة هنا:

[ 87.030967] BTRFS info (device vdf): csum failed ino 258 off 0 csum 3377436548 private 796777854

[ 87.031188] BTRFS info (device vdf): csum failed ino 258 off 0 csum 3377436548 private 796777854

[ 87.031678] btrfs read error corrected: ino 258 off 0 (dev /dev/vde sector 267344)

ألا يعجبك هذا؟

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

هذه خاصية في غاية الروعة ، ففي ZFS تم إنقاذ بياناتي من الضياع في حالات كثيرة ، إنه ليس غريبا أن ترى ٥ أو ١٠ أو ٥٠ خطأ في نتيجة للتحقق في القرص إذا كان يعمل منذ عدة سنوات، وفي بعض الحالات رأيت قوائم raidZ مع أكثر من مئة ألف خطأ في التحقق في قرص واحد ولم تضع أي من البيانات أو أصابها عطب ما.

إذا كنت تهتم ببياناتك و إذا كنت تهتم بشكل خاص بإنقاذ بياناتك لتعيش لعقود أو أكثر ، فأنت تحتاج لهذه الخاصية بشكل أكيد.

إدارة الحجم

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

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

التوسع للمستقبل البعيد

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

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

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

التكرار التزايدي غير المتماثل

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

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

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

 

المساحة اليسرى: جهازك بالكامل في بداية كل ساعة. المساحة اليمنى: جهازك الكامل في بداية كل ساعة من على جهاز بعيد.

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

 

مواصفات خاصة ب btrfs فقط

في القسم الأخير، عرضت ما اعتبره المواصفات المبدئية للجيل المقبل من أنظمة الملفات، لكن btrfs يقدم بعضا من الخصائص الجديدة والتي لا توجد في ZFS.

الاستنساخ على مستوى الملفات

هذا في الحقيقة لأمر هائل، فأنا أعمل كثيرا على الأجهزة الافتراضية، مما يعني أني أملك الكثير والكثير من الملفات التي تتراوح أحجامها بين 5 جيجابايت حتى 400 جيجابايت (وأحيانا أكبر) الموجودة على مختلف الأنظمة. الاستنساخ على مستوى الملفات يعني أنه يمكني أن استنسخ نسخة قابلة للكتابة لأي من الملفات ذات الأحجام الهائلة في ثوان.

me@server:~$ cp --reflink=always 200GB_virtual_machine_drive.qcow2 clone_of_200GB_virtual_machine_drive.qcow2

الأمر الموضح في الأعلى سينسخ 200 جيجابايت من البيانات في ملي ثانية، أثناء النسخ، لن لا توجد الحاجة إلى أي مساحة إضافية على الأقراص، فملف

clone_of_200GB_virtual_machine_drive.qcow2

سيقوم بالإشارة إلى نفس كتل البيانات، بينما أنا أكتب هذا الملف، كل كتلة من البيانات تُكتب كأنها كتلة جديدة ومع مرور الوقت، سيختلف الملف عن أصله كلما احتاج إلى ذلك-- للتأكيد إذا احتاج الأمر فقط.

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

على العكس من ذلك، إذا كنت تريد أن تستخلص ملفات بعينها من لقطات ZFS (أو من النسخ الابتدائية في NTFS او LVM) ستحتاج في الحقيقة إلى نسخها بالكامل قطاع قطاع وبذلك ستستهلك مساحة من قرصك كما أن هنالك احتمالية بأن هذه العملية ستستغرق وقتا لتتم إذا كانت كمية البيانات كبيرة. بغض النظر عن مساحة القرص المهدرة، ستستغرق عملية نسخ صورة النظام الافتراضي ذات 200 جيجابايت مساحة التي ذكرتها في مثالي على الأقل 3 ساعات أو أكثر لتتم نسخها من لقطة ZFS.

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

موازنة متصلة

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

btrfs من جهة أخرى، يسمح لك بعمل أي شيء بخصوص إعادة التعيين للمساحة الحية، لنقل إنك تود تثبيت نظام بقرصين في قائمة من btrfs-raid1 ٫ أولا: ستمضي مع عملية تنصيب لينكس وقم بعملية تنصيب اعتيادية على القرص الأول واجعله جاهزا للعمل من خلال ذلك القرص، ولا تقلق بشأن القرص الثاني،" هل كل شيء جاهز؟ حان الوقت لنتأكد الآن من معرفة رقم الجزء الذي نستخدمه:

me@machine:~$ sudo btrfs filesystem show

Label: none uuid: c9c5e506-6b87-4741-9017-f416d2f2ae8c

Total devices 1 FS bytes used 1.41GB

devid 1 size 9.31GB used 3.54GB path /dev/vda1

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

me@machine:~$ sudo sfdisk -d /dev/vda | sudo sfdisk /dev/vdb

me@machine:~$ sudo grub-install /dev/vdb

 

الآن نضيف التجزيء الأول للقرص الثاني لنظام ملفات منbtrfs :

me@machine:~$ sudo btrfs device add /dev/vdb1 /

ثم نقوم بإعادة التوازن لنظام الملفات باستخدام btrfs-raid1

me@machine:~$ sudo btrfs balance start -dconvert=raid1 -mconvert=raid1 /

سيحدث الجهاز بعض الأصوات التي تدل على قيامه بنسخ الملفات من القرص الأول للقرص الثاني، موجه الأوامر لن يرجع للخدمة إلا في حالة انتهاء العملية. لكن – وهذا هو الجزء الجميل – أن النظام ما يزال قابلا للعمل عليه حتى مع حدوث عملية النسخ! حيث تستطيع تصفح الإنترنت، أو لعب سولتير أو أن تقوم بفتح موجهات الأوامر، أي أن تقوم بما يعجبك، في خلال لحظات قليلة، إذا كان هذا نظام خالي من الأعطال يفترض أن تنتهي العملية بسرعة، وتكون قد حصلت على نظام من btrfs-raid1 يعمل.

هذا مثير للإعجاب بحد ذاته، لكن أيضا يمكنك أن تضيف قرصا ثالثا وتقوم بإعادة التوازن بجعل قيم -dconvert=raid5 -mconvert=raid5، أو إضافة قرص رابع حتى واستخدام ريد10 أو ريد 6. تستطيع القيام بأي إضافات تعجبك. سيكون Btrfs سعيدا تمام بتحويل أي مستوى ريد إلى أي مستوى ريد ثان بسلاسة حتى أثناء عمل النظام. وهذه ميزة ستهم الهواة وأصحاب الأعمال الصغيرة والذين لا يملكون القدرة على بناء نظام كامل ونقل البيانات له.

نو داتا كاو NODATACOW

إحدى أشهر الشكاوى بخصوص الجيل المقبل من أنظمة الملفات هي أنك في حالة غمرت النظام بشكل مفرط بسيل غير منتهي من البيانات العشوائية ستنهار بشكل أسرع من أنظمة الملفات الاعتيادية. لذلك -سيمضي التفكير بأن - Btrfs وZFS لن يكونا الخيار الأفضل لقاعدة بيانات من نوع آبر او مستضيف افتراضي تجريبيbotnet ذي 128نواة و 256GB من الذاكرة العشوائية الذي ربما فكرت في بنائه.

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

من خلال تجربتي ، الغالبية العظمى في حالات ضغط العمل – وتشمل قواعد البيانات و الاستضافة الافتراضية في أغلب ظروف الضغط - ستعمل بشكل جيد تحت نظام ملفات النسخ أثناء الكتابة، لذا لن أتسرع وأفعل هذه الميزة في كل مكان. في القليل من الاختبارات التي قمت بها تشغيل نو داتا كاو لمجلد يحوي صورة لخادم ويندوز 2008 نتج عنه زيادة من 5 إلى 10 بالمئة في الأداء في أفضل الأحوال عند اختبار HDTune Pro في مساحة تخزينه. وستتنازل عن ميزة التحقق لكل كتلة عند تفعيل نو داتا كاو. إنها ميزة موجودة ، و ممتع وجودها لكن مثل أغلب الأشياء ، لا تستخدمها حتى تتأكد أنك تريد استخدامها فعليا.

ضغط على مستوى الملفات أو المجلدات

يقدم ZFS خدمة الضغط لكنها تحتاج إلى أن تكون مفعلة على مستوى النظام بالكامل، يوفر Btrfs ميزة الضغط أيضا باستخدام خوارزميات مختلفة (حاليا gz هو الافتراضي و تعمل خوارزمية lzo بشكل رائع) لكن Btrfs يسمح لك بالتحكم في الضغط على مستوى نظام الملفات، أو الأحجام، أو المجلدات، حتى على مستوى الملفات الفردية. تستطيع أيضا بعمل أشياء رائعة من مثل أنه يمكنك اختيار ضغط كل شيء إلا الملفات التي تنتهي بـ .jpg أو .jpeg أو .avi لأن هذا النوع من الملفات تأتي في صورة مضغوطة بشكل افتراضي ولأن الضغط العام سيزيد حجمها وتخسر بذلك عددا من دورات CPU. (هذا التصرف مفعل بشكل افتراضي، ولا تحتاج حتى إلى إعداده)

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

طريقة استخدام المميزات: تطبيق سريع

لننظر إلى نظام ملفات من نوع Btrfs:

me@virtual-machine:~$ sudo btrfs filesystem show

failed to open /dev/sr0: No medium found

Label: none uuid: e5398102-7f0f-41e6-92f8-bc05176aa3ae

Total devices 1 FS bytes used 3.03GB

devid 1 size 24.00GB used 6.04GB path /dev/vda1

 

Btrfs v0.20-rc1

نظام الملفات Btrfs هذا تم إنزاله على نظام تشغيل ابونتو سوسي مثبت على جهاز افتراضي، بحد ذاته لا يبدو غنيا بالمعلومات ولكن تتضح فائدته إذا كنت تعمل على عدة أنظمة ملفات أو نظام ملفات واحد ولكنه متوزع على عدد من الأجهزة من مثل مصفوفة btrfs-raid0/1/5/6/10

الآن لنلقي نظرة على الحجم لهذا النظام

me@virtual-machine:~$ sudo btrfs sub list /

ID 256 gen 199294 top level 5 path @

ID 257 gen 199294 top level 5 path @home

ما ننظر إليه هنا هو التثبيت الاعتيادي لـ Btrfs على نظام أبونتو / مجلد للمصدر (الجذر) و آخر للمنزل ، هذا يسمح لك (وفي الحقيقة يتطلب منك) لأخذ لقطات لكل مجلد بشكل منفصل، مما يجعله من السهل أرشفة أي منها أو القيام بالتراجع باستخدام أي منهما. فمثلا يمكنك استرجاع النظام الأساسي للملفات بعد أن قمت بترقية مريعة بدون أن تتأثر بياناتك التي قمت تخزينها في مسار المنزل، كما يمكننا رؤية ذلك منعكسا في ملف /etc/fstab

# /etc/fstab: static file system information.

#

# Use 'blkid' to print the universally unique identifier for a

# device; this may be used with UUID= as a more robust way to name devices

# that works even if disks are added and removed. See fstab(5).

#

#

proc /proc proc nodev,noexec,nosuid 0 0

# / was on /dev/sda5 during installation

UUID=bf9ea9b9-54a7-4efc-8003-6ac0b344c6b5 / btrfs defaults,subvol=@ 0 1

# /home was on /dev/sda5 during installation

UUID=bf9ea9b9-54a7-4efc-8003-6ac0b344c6b5 /home btrfs defaults,subvol=@home 0 2

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

me@virtual-machine:~$ sudo btrfs sub create /home/.snapshots

Create subvolume '/home/.snapshots'

الآن، لنأخذ أولا لقطتنا:

me@virtual-machine:~$ sudo btrfs sub snapshot -r /home /home/.snapshots/myfirstsnapshot

Create a readonly snapshot of '/home' in '

نستطيع أن نرى التركيب الجديد في قائمة أخرى من مجلد فرعي في btrfs:

me@virtual-machine:~$ sudo btrfs sub list /

ID 256 gen 199294 top level 5 path @

ID 257 gen 199294 top level 5 path @home

ID 849 gen 199310 top level 5 path @home/.snapshots

ID 850 gen 199311 top level 5 path @home/.snapshots/myfirstsnapshot

 

 

الآن، لننشئ نسخة مكررة للجهاز الثاني والذي يحتوي على مجلدات فرعية ملائمة سميناه \باك اب و \باك اب هوم و \باك اب هوم.سنابشوت

me@virtual-machine:~$ sudo btrfs send /home/.snapshots/myfirstsnapshot | ssh second-machine sudo btrfs receive /backup/home/.snapshots

في أبسط صورة، هذا المثال يوضح طريقة إرسال لقطة – والذي تحتوي على المجلدات الفرعية في وقت التقاط اللقطة وتذكر أنه تم تمريرها عبر ssh الخاصة بنظام الملفات في btrfs في الجهاز الآخر – لا يوجد شيئ مميز هنا حتى الآن، حسنا، صحيح أنك تقوم بنسخ كل المجلدات الفرعية في وقت واحد وهو ما يعتبر مميزا ولكنك يمكنك فعل هذا بطرق أخرى، ما يجعل هذا الأمر رهيبا هو ما سنفعله حين نأخذ لقطتنا الثانية:

me@virtual-machine: sudo btrfs sub snapshot -r /home /home/.snapshots/mysecondsnapshot

me@virtual-machine: sudo btrfs send -p /home/.snapshots/myfirstsnapshot /home/.snapshots/mysecondsnapshot | ssh second-machine btrfs receive /backup/home/.snapshots

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

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

عظيم! من أين أبدأ؟

WARNING! - Btrfs Btrfs v0.20-rc1 IS EXPERIMENTAL

WARNING! - see http://btrfs.wiki.kernel.org before using

 

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

أكثر من ذلك، بينما تعتبر خاصية on-disk format الآن مستقرة وثابتة ولا يتوقع منها التغيير، ما زال Btrfs يتطور بسرعة مما يعني أنه من الأفضل لك أن تستعمل آخر إصدارات نواة لينكس لاختباره، بدأت رحلتي مع Btrfs مع آخر إصدارات النواة في أبونتو وانتهيت بأن قفزت خطوتين للأمام لتجربة النواة في الإصدارات اليومية والتي تقع خارج دائرة رفاهيتي.

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

لكنك إذا كنت مصر على القفز واختبار واستخدام Btrfs، حسنا استمتع به !ولكن تأكد من قراءة صفحة الويكي على هذا الرابط بشكل جيد http://btrfs.wiki.kernel.org 

كما أنصح بالانضمام للقائمة البريدية لـ Btrfs (ذكر عنوانها في صفحة الويكي سابقة الذكر) كما أن موقع تتبع العللBugzilla المتوفر في موقع النواة

kernel.org من المواقع المهمة جدا لرؤية العلل التي ما زالت مفتوحة أو كتابة العلل التي ستصادفك.

الخاتمة

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

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

 

كل ملف هو عبارة عن النظام بأكمله، قابل للتصفح بشكل كلي، وكل ملف يوجد على خادم محلي ونفسه أيضا يوجد على خادم بعيد، هل أرشيفاتك من السهل فهمها واستخدامها؟

يحافظ Btrfs و ZFS على بياناتك ضد كل ما يمكن أن يدمرها بأفضل شكل ممكن، من الممكن عدم ملاحظة هذا الأثر في بداية الأمر لأن لا أحد منا بحوزته بياناته منذ 20 عاما، ففي عام 1994 كان الأمر لمعظم الناس أن الحواسيب هي مجرد أجهزة ومنفصلة عن الحياة الواقعية لذا نحن لا نشعر بفقدانها الآن، لكن في 2014 نحن نوثّق حياتنا بشكل مباشر على الأجهزة وبشكل متزايد وفقط على أجهزتنا. في عام 2034 سيكون الفرق بين النظام الحالي والنظام الأسبق من أنظمة الملفات واضحا كالفرق بين الأفلام و الصور الشمسية الآن.

 

الصورة الأصلية

الصورة بعد قلب بت واحد

الصورة بعد قلب بتان

الصورة بعد قلب ثلاثة بتات

 

هذه التدوين تم تحديثها لتتوافق مع حقيقة ان كاتبات VSS يمكن تعطيلها لإصلاح خطأ الحساب.

 

جيم سالتر (@jrssnet)، مؤلف و متحدث عام، ومالك مشروع صغير ومدير نظام على حسب الطلب، وأب لثلاثة أبناء – ليس بالضرورة بالترتيب. كانت أول تجربة له مع البرامج مفتوحة المصدر عندما شغل مخدم أباتشي على خادمه FreeBSD 3.1 في عام 1999، وأصبح منذ ذلك اليوم مدافع وناشر قوي للبرمجيات الحرة. وقام بإنشاء موقع http://freebsdwiki.net و http://ubuntuwiki.net.