الاسم¶

btrfs - موضوعات حول نظام ملفات BTRFS (خيارات الوصل، وسمات الملفات المدعومة وغيرها)

الوصف¶

يصف هذا المستند موضوعات متعلقة بنظام BTRFS غير مقتصرة على الأدوات. ويغطي حاليا:

1.: خيارات الوصل
2.: ميزات نظام ملفات
3.: دعم ملف التبديل
4.: خوارزميات المجموع التحققي
5.: الضغط
6.: واجهة sysfs
7.: عمليات نظام ملفات الحصرية
8.: حدود نظام ملفات
9.: دعم محمل الإقلاع
10.: سمات الملف
11.: الوضع المقسم
12.: جهاز التحكم
13.: أنظمة ملفات ذات تشكيلات مجموعات كتل متعددة
14.: جهاز البذر
15.: حالة RAID56 والممارسات الموصى بها
16.: المسرد
17.: نموذج التخزين، اعتبارات العتاد

خيارات الوصل¶

خيارات الوصل الخاصة بنظام BTRFS¶

يصف هذا القسم خيارات الوصل الخاصة بـ BTRFS. لمعرفة خيارات الوصل العامة، يرجى الرجوع إلى صفحة دليل mount(8) وانظر أيضًا قسم خصائص BTRFS أدناه. تُفرز الخيارات أبجديًا (مع تجاهل البادئة no).

ملاحظة:

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

تُعالج خيارات الوصل بالترتيب، حيث يسري الظهور الأخير للخيارات فقط، وقد يؤدي إلى تعطيل خيارات أخرى بسبب القيود (انظر على سبيل المثال nodatacow و compress). يظهر مخرج الأمر mount الخيارات التي طُبقت.

acl, noacl

(مبدئي: مفعل)

تمكين/تعطيل دعم قوائم التحكم بالوصول POSIX‏ (ACLs). انظر صفحة دليل acl(5) لمزيد من المعلومات حول قوائم التحكم بالوصول.

يمكن ضبط دعم قوائم ACL وقت البناء عبر (BTRFS_FS_POSIX_ACL)، ويفشل الوصل إذا طُلب الخيار acl ولم تكن الميزة مجمعة في النواة.

autodefrag, noautodefrag

(منذ: 3.0، مبدئي: معطل)

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

قد يزداد زمن انتقال القراءة بسبب قراءة الكتل المتجاورة التي تشكل نطاق إلغاء التجزئة، وستدمج عمليات الكتابة المتعاقبة الكتل في الموقع الجديد.

تحذير:

يؤدي إلغاء التجزئة مع إصدارات نواة Linux ‏< 3.9 أو ≥ 3.14-rc2 وكذلك مع إصدارات نواة Linux المستقرة ≥ 3.10.31 أو ≥ 3.12.12 أو ≥ 3.13.4 إلى كسر روابط الإحالة المرجعية (reflinks) لبيانات COW (على سبيل المثال الملفات المنسوخة بـ cp --reflink، أو اللقطات، أو البيانات الملغى تكرارها). قد يتسبب هذا في زيادة كبيرة في استخدام المساحة اعتمادا على الروابط المكسورة.

barrier, nobarrier

(مبدئي: مفعل)

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

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

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

clear_cache

فرض مسح وإعادة بناء خبيئة المساحة الحرة إذا حدث خطأ ما.

بالنسبة لخبيئة المساحة الحرة من الإصدار v1، يمسح هذا الخيار فقط (ويعيد بناءها، ما لم يُستخدم nospace_cache) لمجموعات الكتل التي عُدلت أثناء وصل نظام الملفات بهذا الخيار. لمسح خبيئة المساحة الحرة بالكامل من الإصدار v1 فعلًا، انظر btrfs check --clear-space-cache v1.

بالنسبة لخبيئة المساحة الحرة من الإصدار v2، يمسح هذا الخيار خبيئة المساحة الحرة بالكامل. للقيام بذلك دون الحاجة إلى وصل نظام الملفات، انظر btrfs check --clear-space-cache v2.

انظر أيضًا: space_cache.

commit=<seconds>

(منذ: 3.12، مبدئي: 30)

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

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

compress, compress=<type[:level]>, compress-force, compress-force=<type[:level]>

(مبدئي: معطل، دعم تحديد المستوى منذ: 5.1)

التحكم في ضغط بيانات ملفات BTRFS. يمكن تحديد النوع كـ zlib أو lzo أو zstd أو no (لعدم الضغط، ويستخدم عند إعادة الوصل). إذا لم يحدد أي نوع، فيُستخدم zlib. وإذا حدد compress-force، فسيُحاول الضغط دائما، ولكن قد تنتهي البيانات دون ضغط إذا كان الضغط سيجعل حجمها أكبر.

يوفر كل من zlib و zstd (منذ الإصدار 5.1) مستوى الضغط كمقبض قابل للضبط، حيث تقايض المستويات الأعلى السرعة والذاكرة (في zstd) بمعدلات ضغط أعلى. يمكن ضبط ذلك بإلحاق نقطتين رأسيتين والمستوى المطلوب. يقبل ZLIB النطاق [1, 9] ويقبل ZSTD النطاق [1, 15]. إذا لم يحدد أي مستوى، يستخدم كلاهما حاليا المستوى المبدئي 3. تمثل القيمة 0 اسمًا مستعارًا للمستوى المبدئي.

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

ملاحظة:

إذا فُعل الضغط، يُعطل الخياران nodatacow و nodatasum.

datacow, nodatacow

(مبدئي: مفعل)

تمكين نسخ البيانات عند الكتابة للملفات المنشأة حديثًا. يتضمن خيار Nodatacow خيار nodatasum، ويعطل compression. جميع الملفات المنشأة تحت nodatacow تُعين لها أيضًا سمة الملف NOCOW (انظر chattr(1)).

ملاحظة:

إذا فُعل nodatacow أو nodatasum، يُعطل الضغط.

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

datasum, nodatasum

(مبدئي: مفعل)

تمكين حساب المجموع التحققي للبيانات للملفات المنشأة حديثًا. يتضمن خيار Datasum خيار datacow، أي نمط التشغيل العادي. جميع الملفات المنشأة تحت nodatasum ترث خاصية "لا مجاميع تحققية"، ومع ذلك لا توجد سمة ملف مقابلة (انظر chattr(1)).

ملاحظة:

إذا فُعل nodatacow أو nodatasum، يُعطل الضغط.

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

degraded

(مبدئي: معطل)

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

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

مثال: البيانات الواصفة -- raid1، البيانات -- مفردة (single)، الأجهزة -- /dev/sda، /dev/sdb

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

device=<devicepath>: تحديد مسار لجهاز سيُفحص للبحث عن نظام ملفات BTRFS أثناء الوصل. يُجرى هذا عادة آليًّا بواسطة مدير الأجهزة (مثل udev) أو باستخدام الأمر btrfs device scan (على سبيل المثال، تشغيله من قرص الرام المبدئي). وفي الحالات التي لا يكون فيها ذلك ممكنا، يمكن أن يساعد خيار الوصل device.
ملاحظة:

قد يفشل إقلاع نظام RAID1 على سبيل المثال حتى لو وُفرت جميع مسارات device الخاصة بنظام الملفات، لأن عقد الأجهزة الفعلية قد لا يكتشفها النظام في تلك المرحلة.

discard, discard=sync, discard=async, nodiscard

(مبدئي: غير متزامن (async) عندما تدعمه الأجهزة منذ 6.2، ودعم الوضع غير المتزامن منذ: 5.6)

تمكين إهمال (discard) كتل الملفات المحررة. يفيد هذا لأجهزة SSD/NVMe، أو وحدات LUN ذات التجهيز الخفيف، أو صور الأجهزة الافتراضية؛ ومع ذلك، يجب أن تدعم كل طبقة تخزين ميزة الإهمال لكي تعمل.

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

يجمع الوضع غير المتزامن (async) النطاقات (extents) في قطع أكبر قبل إرسالها إلى الأجهزة لإجراء عملية TRIM. يفترض أن يكون العبء الإضافي والأثر على الأداء ضئيلين مقارنة بالوضع السابق، ويُفترض أن يكون هو الوضع المفضل إذا لزم الأمر.

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

enospc_debug, noenospc_debug

(مبدئي: معطل)

تمكين المخرج المسهب لبعض حالات نفاد المساحة (ENOSPC). استخدامه آمن ولكن قد يكون صاخبًا ومكثرًا للرسائل إذا اقترب النظام من الامتلاء التام.

fatal_errors=<action>

(منذ: 3.4، مبدئي: bug)

الإجراء الواجب اتخاذه عند مواجهة خطأ فادح.

bug: عند حدوث خطأ فادح عبر BUG()، سيبقى النظام في حالة الانهيار وقد يظل قابلا للاستخدام جزئيا، ولكن يلزم إعادة التشغيل للعمل بشكل كامل
panic: عند حدوث خطأ فادح عبر panic()، وبناء على إعدادات النظام الأخرى، قد يعقب ذلك إعادة التشغيل. يرجى الرجوع إلى وثائق معلمات إقلاع النواة، مثل panic أو oops أو crashkernel.

flushoncommit, noflushoncommit

(مبدئي: معطل)

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

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

عند إيقافه، يكون نظام الملفات متسقا ولكن عمليات الكتابة المخبوءة (buffered) قد تستغرق أكثر من إيداع معاملة واحدة.

fragment=<type>

(يعتمد على خيار وقت التجميع CONFIG_BTRFS_DEBUG، منذ: 4.4، مبدئي: معطل)

مساعد تنقيح لتجزئة نوع type معين من مجموعات الكتل عمدًا. يمكن أن يكون النوع data أو metadata أو all. لا ينبغي استخدام خيار الوصل هذا خارج بيئات التنقيح ولا يُتعرف عليه إذا لم يكن خيار إعداد النواة CONFIG_BTRFS_DEBUG مفعلا.

nologreplay

(مبدئي: معطل، حتى في وضع القراءة فقط)

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

تحذير:

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

max_inline=<bytes>

(مبدئي: الحد الأدنى بين (2048، وحجم الصفحة) )

تحديد الحد الأقصى للمساحة التي يمكن إدراجها مباشرة (inline) في ورقة شجرة b-tree للبيانات الواصفة. تحدد القيمة بالبايت، اختياريًّا مع اللاحقة K (غير حساسة لحالة الأحرف). عمليًّا، تكون هذه القيمة محدودة بحجم كتلة نظام الملفات (المسمى sectorsize وقت إنشاء نظام الملفات عبر mkfs)، وحجم صفحة الذاكرة في النظام. في حالة حد حجم القطاع (sectorsize)، تكون بعض المساحة غير متاحة بسبب ترويسات أوراق b-tree. على سبيل المثال، إذا كان حجم القطاع 4KiB، فإن الحجم الأقصى للبيانات المدرجة مباشرة هو حوالي 3900 بايت.

يمكن إيقاف الإدراج المباشر تمامًا بتحديد القيمة 0. سيؤدي هذا إلى زيادة الفاقد (slack) في كتل البيانات إذا كانت أحجام الملفات أصغر بكثير من حجم الكتلة، ولكنه سيقلل في المقابل من استهلاك البيانات الواصفة.

ملاحظة:

تغيرت القيمة المبدئية إلى 2048 في النواة 4.6.

metadata_ratio=<value>

(مبدئي: 0، منطق داخلي)

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

norecovery

(منذ: 4.5، مبدئي: معطل)

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

ملاحظة:

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

rescan_uuid_tree: (منذ: 3.12، مبدئي: معطل)
فرض إجراء فحص وإعادة بناء لشجرة UUID. لا ينبغي أن يكون هذا مطلوبًا في الوضع الطبيعي. بدلاً من ذلك، يمكن مسح الشجرة من فضاء المستخدم عبر الأمر btrfs rescue clear-uuid-tree ثم ستُعاد بناؤها آليًا في النواة (ولا حاجة لخيارات الوصل في هذه الحالة).
rescue: (منذ: 5.9)
أطوار تسمح بالوصل مع وجود بنيات تالفة في نظام الملفات، وتتطلب جميعها أن يُوصل نظام الملفات في طور القراءة فقط ولا تسمح بإعادة الوصل للقراءة والكتابة. يُفترض أن يوفر هذا ضبطًا موحدًا وأكثر دقة للأخطاء التي تؤثر على عملية نظام الملفات.

usebackuproot (منذ 5.9)
محاولة استخدام فتحات الجذور الاحتياطية داخل الكتلة الفائقة. يحل محل الخيار المستقل usebackuproot
nologreplay (منذ 5.9)
عدم إعادة تشغيل أي سجلات غير نظيفة. يحل محل الخيار المستقل nologreplay
ignorebadroots،‏ ibadroots (منذ: 5.11)
تجاهل جذور الشجرة الفاسدة، مما يحسن فرصة إنقاذ البيانات بشكل كبير.
ignoredatacsums،‏ idatacsums (منذ: 5.11)
تجاهل التحقق من المجموع التدقيقي للبيانات.
ignoremetacsums،‏ imetacsums (منذ 6.12)
تجاهل التحقق من المجموع التدقيقي للبيانات الوصفية، وهو مفيد في حالة انقطاع عملية تحويل المجموع التدقيقي.
all (منذ: 5.9)
تمكين كل خيارات الإنقاذ المدعومة.

skip_balance

(منذ: 3.3، المبدئي: معطل)

تخطي الاستئناف الآلي لعملية موازنة مقطوعة. يمكن استئناف العملية لاحقًا عبر btrfs balance resume، أو يمكن إزالة حالة الإيقاف المؤقت باستخدام btrfs balance cancel. السلوك المبدئي هو استئناف الموازنة المقطوعة مباشرة بعد وصل نظام الملفات.

space_cache, space_cache=<version>, nospace_cache

(nospace_cache منذ: 3.2، و space_cache=v1 و space_cache=v2 منذ 4.5، المبدئي: space_cache=v2)

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

هناك تطبيقان لخبيئة المساحة الحرة. التطبيق الأصلي، ويشار إليه باسم v1، كان يُعد خيارًا مبدئيًّا آمنًا ولكنه استُبدل بالتطبيق v2. يمكن تعطيل خبيئة المساحة v1 عند وقت الوصل باستخدام nospace_cache دون مسحها.

في نظم الملفات الكبيرة جدًّا (العديد من التيرايبايتات) وبعض أعباء العمل المعينة، قد يتدهور أداء خبيئة المساحة v1 بشكل حاد. يعالج تطبيق v2 هذه المشكلة، حيث يضيف شجرة b-tree جديدة تسمى شجرة المساحة الحرة. بمجرد تمكينه، ستُستخدم خبيئة المساحة v2 دائمًا ولا يمكن تعطيلها إلا إذا مُسحت. استخدم clear_cache,space_cache=v1 أو clear_cache,nospace_cache للقيام بذلك. إذا مُكنت v2، ستُمسح خبيئة المساحة v1 (عند أول وصل) ولن تتمكن النوى التي تفتقر إلى دعم v2 إلا من وصل نظام الملفات في طور القراءة فقط. يمكن مسح الخبيئتين (بكلا الإصدارين) على نظام ملفات مفصول عبر الأمر "btrfs check --clear-space-cache".

تمتلك الأوامر btrfs-check(8) و :doc:`mkfs.btrfs دعمًا كاملاً لخبيئة المساحة الحرة من الإصدار v2 منذ الإصدار v4.19.

إذا لم يُحدد إصدار بشكل صريح، فسيُختار التطبيق المبدئي، وهو v2.

ssd, ssd_spread, nossd, nossd_spread

(المبدئي: رُصد قرص SSD آليًّا)

خيارات للتحكم في مخططات تخصيص أقراص SSD. سيمكن نظام BTRFS تحسينات SSD أو يعطلها مبدئيًّا بناءً على حالة الجهاز فيما يتعلق بنوعه الدوراني أو غير الدوراني. يُحدد هذا عبر محتويات الملف /sys/block/DEV/queue/rotational). إذا كانت القيمة 0، يُفعل الخيار ssd. ويعطل الخيار nossd هذا الرصد الآلي.

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

ملاحظة:

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

يحاول خيار الوصل ssd_spread التخصيص في قطع أكبر ومحاذاة من المساحة غير المستخدمة، وقد يقدم أداءً أفضل على أقراص SSD منخفضة التكلفة. يتضمن الخيار ssd_spread الخيار ssd ضمنيًّا، مما يمكن جميع القواعد التجريبية الأخرى لأقراص SSD أيضًا. يعطل الخيار nossd كل خيارات SSD، بينما يعطل nossd_spread الخيار ssd_spread فقط.

subvol=<path>: وصل حجم فرعي من path بدلًا من الحجم الفرعي ذي المستوى الأعلى. يُعامل path دائمًا على أنه نسبي للحجم الفرعي ذي المستوى الأعلى. يتجاوز خيار الوصل هذا الحجم الفرعي المبدئي المحدد لنظام الملفات المعني.
subvolid=<subvolid>: وصل حجم فرعي محدد برقم subvolid بدلًا من الحجم الفرعي ذي المستوى الأعلى. يمكنك استخدام الأمر btrfs subvolume list أو الأمر btrfs subvolume show لرؤية أرقام معرفات الأحجام الفرعية. يتجاوز خيار الوصل هذا الحجم الفرعي المبدئي المحدد لنظام الملفات المعني.
ملاحظة:

إذا حُدد كل من subvolid و subvol، فيجب أن يشيرا إلى نفس الحجم الفرعي، وإلا ستفشل عملية الوصل.

thread_pool=<number>

(المبدئي: min(NRCPUS + 2, 8) )

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

treelog, notreelog

(مبدئي: مفعل)

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

تحذير:

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

يمكن أن يحتوي سجل الشجرة على ملفات/أدلة جديدة، ولن تكون موجودة على نظام ملفات موصول إذا لم يُعد تشغيل السجل.

usebackuproot

(منذ: 4.6، المبدئي: معطل)

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

ملاحظة:

حل هذا الخيار محل recovery الذي أُهمِل.

user_subvol_rm_allowed

(مبدئي: معطل)

السماح بحذف الأحجام الفرعية من قِبل مالكها المعني. خلاف ذلك، يمكن للمستخدم الجذر (root) فقط القيام بذلك.

ملاحظة:

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

خيارات الوصل المهملة¶

قائمة خيارات الوصل التي أُزيلت، مع الإبقاء عليها من أجل التوافقية الرجعية.

recovery: (منذ: 3.2، المبدئي: معطل، مهمل منذ: 4.5)
ملاحظة:

استُبدل هذا الخيار بالخيار usebackuproot ولا ينبغي استخدامه، ولكنه سيعمل على النوى بالإصدار 4.5 فما فوق.

inode_cache, noinode_cache: (أُزيل في: 5.11، منذ: 3.0، المبدئي: معطل)
ملاحظة:

أُزيلت الوظيفة في الإصدار 5.11، ويمكن إزالة أي بيانات قديمة أُنشئت بواسطة الاستخدام السابق لخيار inode_cache عبر btrfs rescue clear-ino-cache.

check_int, check_int_data, check_int_print_mask=<value>

(أُزيل في: 6.7، منذ: 3.0، المبدئي: معطل)

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

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

يضمن خيار check_int_data بيانات المدى في فحص السلامة، ويتضمن الخيار check_int ضمنيًّا.

يأخذ الخيار check_int_print_mask قناع بتات من قيم BTRFSIC_PRINT_MASK_* كما هي معرفة في الملف fs/btrfs/check-integrity.c، للتحكم في سلوك وحدة فاحص السلامة.

راجع التعليقات الموجودة في أعلى الملف fs/btrfs/check-integrity.c لمزيد من المعلومات.

ملاحظات حول خيارات الوصل العامة¶

بعض خيارات الوصل العامة من mount(8) التي تؤثر على BTRFS وتستحق الذكر.

context: يشير السياق إلى سياقات SELinux وتعاريف السياسات الممررة كخيارات وصل. يعمل هذا بشكل صحيح منذ الإصدار v6.8 (لأن محلل خيارات الوصل لـ BTRFS نُقل إلى واجهة برمجة تطبيقات جديدة تفهم هذه الخيارات أيضًا).
noatime: تحت أعباء العمل المكثفة للقراءة، فإن تحديد noatime يحسن الأداء بشكل ملحوظ لأنه لا حاجة لكتابة معلومات وقت وصول جديدة. وبدون هذا الخيار، يكون الخيار المبدئي هو relatime، والذي يقلل فقط من عدد تحديثات وقت وصول الآينود (atime) مقارنة بالخيار التقليدي strictatime. تحدث أسوأ حالة لتحديثات atime تحت خيار relatime عندما تُقرأ ملفات كثيرة يكون وقت وصولها أقدم من 24 ساعة وتكون مأخوذة حديثًا في لقطة. في هذه الحالة يُحدث وقت الوصول ويحدث نسخ عند الكتابة (COW) - لكل ملف - دفعة واحدة. انظر أيضًا https://lwn.net/Articles/499293/ - Atime and btrfs: a bad combination? (LWN, 2012-05-31).
لاحظ أن noatime قد يكسر التطبيقات التي تعتمد على تحديثات وقت الوصول (atime) مثل برنامج Mutt العريق (ما لم تستخدم صناديق بريد maildir).

ميزات نظام الملفات¶

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

هناك عدة فئات والأدوات المقابلة لها لإدارة هذه الميزات:

في وقت mkfs فقط: هذا مخصص للهياكل الرئيسة، مثل حجم عقدة b-tree أو خوارزمية المجموع التحققي، انظر mkfs.btrfs(8) لمزيد من التفاصيل.
بعد mkfs، على نظام ملفات مفصول: الميزات التي قد تحسن الهياكل الداخلية أو تضيف هياكل جديدة لدعم وظائف جديدة، انظر btrfstune(8). سيقوم الأمر btrfs inspect-internal dump-super /dev/sdx بإفراغ الكتلة الفائقة، ويمكنك مطابقة قيمة incompat_flags بالميزات المدرجة أدناه
بعد mkfs، على نظام ملفات موصول: تُدرج ميزات نظام الملفات (الذي له معرف UUID معين) في الدليل /sys/fs/btrfs/UUID/features/، ملف واحد لكل ميزة. وتُخزن الحالة داخل الملف. القيمة 1 تعني أنها مُمكّنة ونشطة، بينما تعني القيمة 0 أن الميزة مُكّنت في وقت الوصل ولكنها أُوقفت بعد ذلك.
يمكن معرفة ما إذا كان يمكن تشغيل ميزة معينة على نظام ملفات موصول في الدليل /sys/fs/btrfs/features/، ملف واحد لكل ميزة. تعني القيمة 1 أن الميزة يمكن تمكينها.

قائمة الميزات (انظر أيضًا قسم FILESYSTEM FEATURES في mkfs.btrfs(8)):

big_metadata

(منذ: 3.4)

يستخدم نظام الملفات الخيار nodesize لكتل البيانات الوصفية، ويمكن أن يكون هذا أكبر من حجم الصفحة

block_group_tree

(منذ: 6.1)

تمثيل عناصر مجموعة الكتل باستخدام شجرة b-tree مخصصة، مما يمكن أن يقلل وقت الوصل بشكل كبير لنظم الملفات الكبيرة

compress_lzo

(منذ: 2.6.38)

اُستخدم ضغط lzo على نظام الملفات، إما كخيار وصل أو عبر الأمر btrfs filesystem defrag.

compress_zstd

(منذ: 4.14)

اُستخدم ضغط zstd على نظام الملفات، إما كخيار وصل أو عبر الأمر btrfs filesystem defrag.

default_subvol

(منذ: 2.6.34)

ضُبط الحجم الفرعي المبدئي على نظام الملفات

extended_iref

(منذ: 3.7)

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

free_space_tree

(منذ: 4.5)

تمثيل المساحة الحرة باستخدام شجرة b-tree مخصصة، وهو خليفة خبيئة المساحة v1

metadata_uuid

(منذ: 5.0)

معرّف UUID لنظام ملفات الرئيس هو metadata_uuid، والذي يخزن معرّف UUID الجديد فقط في الكتلة الفائقة بينما تظل جميع كتل البيانات الوصفية تحتفظ بمعرّف UUID المعين في وقت إنشاء نظام ملفات (mkfs)، انظر btrfstune(8) للمزيد

mixed_backref

(منذ: 2.6.31)

آخر تغيير رئيس في تنسيق القرص، مراجع خلفية محسنة، وهو المبدئي الآن

mixed_groups

(منذ: 2.6.37)

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

من ناحية أخرى، فإن التخطيط النهائي لا يمكن التنبؤ به تمامًا وربما يكون مجزأً للغاية، مما يعني أداءً أسوأ

no_holes

(منذ: 3.14)

تمثيل محسن لمدى الملفات حيث لا تُخزن الفجوات صراحة كمدى، مما يوفر نسبة مئوية قليلة من البيانات الوصفية إذا استُخدمت الملفات المتناثرة

raid1c34

(منذ: 5.5)

طور RAID1 الممتد مع وجود نسخ على 3 أو 4 أجهزة على التوالي

raid_stripe_tree

(منذ: 6.7)

شجرة منفصلة لتتبع مدى الملفات في تشكيلات RAID

RAID56

(منذ: 3.9)

يحتوي نظام الملفات أو كان يحتوي على تشكيلة RAID56 لمجموعات الكتل

rmdir_subvol

(منذ: 4.18)

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

skinny_metadata

(منذ: 3.10)

بيانات وصفية مخفضة الحجم لمراجع الامتداد (extent references)، مما يوفر بضعة نسب مئوية من البيانات الوصفية

send_stream_version

(منذ: 5.10)

رقم أعلى إصدار مدعوم لدفق الإرسال (send stream)

simple_quota

(منذ: 6.7)

محاسبة حصص نسبية مبسطة

supported_checksums

(منذ: 5.5)

قائمة خوارزميات المجموع التحققي المدعومة من وحدة النواة، يجب أن تكون الوحدات المقابلة أو البرمجيات المدمجة التي تطبق الخوارزميات موجودة لوصل نظام ملفات، انظر قسم CHECKSUM ALGORITHMS.

supported_sectorsizes

(منذ: 5.13)

قائمة بالقيم المقبولة كأحجام للقطاعات (mkfs.btrfs --sectorsize) من قبل النواة المشغلة

supported_rescue_options

(منذ: 5.11)

قائمة القيم لخيار الوصل rescue المدعومة من النواة التي تعمل حاليًا، انظر btrfs(5)

zoned

(منذ: 5.12)

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

دعم ملف التبديل¶

ملف التبديل، عندما يكون نشطًا، هو منطقة تبديل مدعومة بملف. وهو مدعوم منذ النواة 5.0. استخدم swapon(8) لتنشيطه، وحتى ذلك الحين (وعند إلغاء تنشيطه مجددًا باستخدام swapoff(8)) يكون مجرد ملف عادي (مع تعيين NODATACOW)، والقيود الخاصة بملفات التبديل النشطة لا تنطبق عليه.

هناك بعض القيود المتعلقة بتطبيق نظام الملفات BTRFS ونظام التخزين المؤقت في لينكس:

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

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

عند وجود ملفات تبديل نشطة، فإن عمليات نظام الملفات الكاملة التالية ستتجاوز امتدادات ملف التبديل أو قد تفشل:

الموازنة (balance) - تُتجاوز مجموعات الكتل التي تحتوي على امتدادات لأي ملفات تبديل نشطة ويُبلّغ عنها، وتعالج بقية المجموعات بشكل طبيعي
تغيير الحجم بالزيادة (resize grow) - لا يتأثر
تغيير الحجم بالتقليص (resize shrink) - يعمل طالما كانت امتدادات أي ملفات تبديل نشطة تقع خارج النطاق المقلص
إضافة جهاز (device add) - إذا لم تتدخل الأجهزة الجديدة مع أي ملفات تبديل نشطة بالفعل، فستعمل هذه العملية، على الرغم من عدم إمكانية تنشيط أي ملف تبديل جديد بعد ذلك
حذف جهاز (device delete) - إذا أُضيف الجهاز كما هو موضح أعلاه، فيمكن حذفه أيضًا
استبدال جهاز (device replace) - الأمر عينه

عند عدم وجود ملفات تبديل نشطة وتكون هناك عملية حصرية لنظام الملفات بالكامل قيد التشغيل (مثل الموازنة، أو حذف الجهاز، أو التقليص)، فلا يمكن تنشيط ملفات التبديل مؤقتًا. يجب أن تنتهي العملية أولاً.

لإنشاء ملف تبديل وتنشيطه، شغّل الأوامر التالية:

# truncate -s 0 swapfile
# chattr +C swapfile
# fallocate -l 2G swapfile
# chmod 0600 swapfile
# mkswap swapfile
# swapon swapfile

منذ الإصدار 6.1، يتاح إنشاء ملف التبديل في أمر واحد (باستثناء التنشيط):

# btrfs filesystem mkswapfile --size 2G swapfile
# swapon swapfile

يرجى ملاحظة أن المعرف الفريد العالمي UUID الذي تعيده أداة mkswap يحدد "نظام ملفات" التبديل، ولأنه مخزن في ملف، فإنه غير مرئي بشكل عام ولا يمكن استخدامه كمعرف بخلاف ما إذا كان على جهاز كتلي.

بمجرد التنشيط، سيظهر الملف في /proc/swaps:

# cat /proc/swaps
Filename          Type          Size           Used      Priority
/path/swapfile    file          2097152        0         -2

يمكن إنشاء ملف التبديل كعملية لمرة واحدة أو تنشيطه عند كل إقلاع بمجرد إنشائه بشكل صحيح بواسطة الأمر swapon -a (الذي يُشغّل عادةً بواسطة مدير الخدمة). أضف المدخل التالي إلى /etc/fstab، بافتراض أن نظام الملفات الذي يوفر المسار /path قد وُصل بالفعل عند هذه النقطة. يمكن أيضًا ضبط خيارات وصل إضافية ذات صلة بملف التبديل (مثل الأولوية، وليس خيارات وصل BTRFS).

/path/swapfile        none        swap        defaults      0 0

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

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

HIBERNATION¶

يمكن استخدام ملف التبديل السبات (hibernation) ولكن الأمر ليس مباشرًا. قبل السبات، يجب كتابة إزاحة الاستئناف (resume offset) إلى الملف /sys/power/resume_offset أو يجب ضبط معطى سطر الأوامر للنواة resume_offset.

هذه القيمة هي الإزاحة المادية على الجهاز. لاحظ أن هذه ليست القيمة نفسها التي يطبعها filefrag كإزاحة مادية!

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

منذ الإصدار 6.1 هناك أمر btrfs inspect-internal map-swapfile يقوم بطباعة الإزاحة الفيزيائية للجهاز والقيمة المعدلة لـ /sys/power/resume_offset. لاحظ أن القيمة مقسومة على حجم الصفحة، أي أنها ليست الإزاحة نفسها.

# btrfs filesystem mkswapfile swapfile
# btrfs inspect-internal map-swapfile swapfile
Physical start: 811511726080
Resume offset:     198122980

لأغراض البرمجة النصية والتسهيل، فإن الخيار -r يطبع الإزاحة فقط:

# btrfs inspect-internal map-swapfile -r swapfile
198122980

يتحقق الأمر map-swapfile أيضًا من جميع المتطلبات، أي عدم وجود فجوات، وكونه جهازًا واحدًا، وما إلى ذلك.

TROUBLESHOOTING¶

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

على وجه الخصوص، تخرج أداة swapon برسالة لا توضح سبب الفشل:

# swapon /path/swapfile
swapon: /path/swapfile: swapon failed: Invalid argument

يُرجح أن يُطبع السبب المحدد في سجل النظام بواسطة وحدة btrfs:

# journalctl -t kernel | grep swapfile
kernel: BTRFS warning (device sda): swapfile must have single data profile

خوارزميات مجموع التحقق¶

تُجرى عملية حساب مجموع التحقق للبيانات والبيانات الوصفية مبدئيًا. يُحسب مجموع التحقق قبل الكتابة ويُتحقق منه بعد قراءة الكتل من الأجهزة. تحتوي كتلة البيانات الوصفية بأكملها على مجموع تحقق مضمن مخزن في ترويسة عقدة شجرة-ب (b-tree). تمتلك كل كتلة بيانات مجموع تحقق منفصل مخزن في شجرة مجموع التحقق.

ملاحظة:

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

يُستوفى هذا الشرط في حالة الكتابة المخبوءة (buffered write) نظرًا لأن btrfs يمتلك التحكم الكامل في خبيئة الصفحات الخاصة به، ولكن الكتابة المباشرة (O_DIRECT) تتخطى خبيئة الصفحات، ولا يمكن لـ btrfs التحكم في مخزن الإدخال/الإخراج المباشر المؤقت (إذ يمكن أن يكون في ذاكرة فضاء المستخدم). وبالتالي، فمن الممكن أن يقوم برنامج في فضاء المستخدم بتعديل مخزن الكتابة المباشرة المؤقت قبل كتابة المخزن بالكامل مادية خلفية، مما قد يؤدي إلى عدم تطابق في مجموع تحقق البيانات.

لتجنب ذلك، ستجبر النواة بدءًا من الإصدار 6.14 الكتابة المباشرة على التراجع إلى الكتابة المخبوءة، إذا كانت عقدة الفهرسة (inode) تتطلب مجموع تحقق للبيانات. سيتسبب هذا في انخفاض طفيف في الأداء. إذا كنت بحاجة إلى كتابات مباشرة حقيقية خالية من النسخ (zero-copy)، فعيّن علم NODATASUM لعقدة الفهرسة وتأكد من محاذاة مخزن الإدخال/الإخراج المباشر المؤقت تمامًا مع حجم الكتلة.

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

CRC32C (ملخص 32 بت): مبدئي، وأفضل توافقية مع الإصدارات السابقة. سريع جدًا، وتمتلك المعالجات الحديثة دعمًا له على مستوى التعليمات، وليس مقاومًا للتصادم ولكنه يمتلك قدرات جيدة في اكتشاف الأخطاء.
XXHASH (ملخص 64 بت): يمكن استخدامه كخليفة لـ CRC32C. سريع جدًا، ومحسن للمعالجات الحديثة التي تستخدم خطوط أنابيب التعليمات (instruction pipelining)، ومقاومة جيدة للتصادم واكتشاف الأخطاء.
SHA256 (ملخص 256 بت): هاش ذو قوة تعمية. بطيء نسبيًا ولكن مع إمكانية تسريعه عبر تعليمات المعالج أو بطاقات العتاد المتخصصة. معتمد من FIPS ومستخدم على نطاق واسع.
BLAKE2b (ملخص 256 بت): هاش ذو قوة تعمية. سريع نسبيًا، مع إمكانية تسريعه باستخدام تمديدات SIMD للمعالج. غير مقيَّس ولكنه يعتمد على BLAKE الذي وصل للتصفيات النهائية لـ SHA3، ومستخدم على نطاق واسع. الخوارزمية المستخدمة هي BLAKE2b-256 المحسنة للمنصات ذات 64 بت.

يؤثر حجم الملخص على الحجم الإجمالي لمجاميع تحقق كتل البيانات المخزنة في نظام الملفات. تمتلك كتل البيانات الوصفية مساحة ثابتة تصل إلى 256 بت (32 بايت)، لذا لا توجد زيادة هناك. كل كتلة بيانات لها مجموع تحقق منفصل مخزن، مع عبء إضافي لأوراق شجرة-ب (b-tree leaves).

الأداء النسبي التقريبي للخوارزميات، مقاسًا مقارنة بـ CRC32C باستخدام تطبيقات على معالج intel من الجيل الحادي عشر بتردد 3.6 جيجاهرتز:

الملخص	Cycles/4KiB	النسبة	التطبيق
CRC32C	470	1.00	تعليمات المعالج، تركيبة PCL
XXHASH	870	1.9	التطبيق المرجعي
SHA256	7600	16	libgcrypt
SHA256	8500	18	openssl
SHA256	8700	18	botan
SHA256	32000	68	مدمج، تعليمات المعالج
SHA256	37000	78	libsodium
SHA256	78000	166	مدمج، التطبيق المرجعي
BLAKE2b	10000	21	builtin/AVX2
BLAKE2b	10900	23	libgcrypt
BLAKE2b	13500	29	builtin/SSE41
BLAKE2b	13700	29	libsodium
BLAKE2b	14100	30	openssl
BLAKE2b	14500	31	kcapi
BLAKE2b	14500	34	مدمج، التطبيق المرجعي

تُضبط العديد من النوايا مع SHA256 كميزة مدمجة وليس كوحدة. ومع ذلك، حتى إصدار النواة v6.15، توفر الوحدات النسخ المسرعة ويجب تحميلها صراحة (modprobe sha256) قبل وصل نظام الملفات للاستفادة منها. يمكنك التحقق في /sys/fs/btrfs/FSID/checksum لمعرفة أي منها مستخدم. إذا رأيت sha256-generic، فقد ترغب في فصل نظام الملفات ووصله مرة أخرى. لا يمكن تغيير ذلك على نظام ملفات موصول.

منذ إصدار النواة v6.16، يُستخدم التطبيق المسرع دائمًا إذا كان متاحًا.

افحص الملف /proc/crypto، عندما يكون التطبيق مدمجًا، ستجد:

name         : sha256
driver       : sha256-generic
module       : kernel
priority     : 100
...

بينما يكون التطبيق المسرع على سبيل المثال:

name         : sha256
driver       : sha256-avx2
module       : sha256_ssse3
priority     : 170
...

COMPRESSION¶

يدعم Btrfs ضغط الملفات الشفاف. تتوفر ثلاث خوارزميات: ZLIB و LZO و ZSTD (منذ v4.14)، بمستويات متنوعة. يحدث الضغط على مستوى امتدادات الملفات وتُحدد الخوارزمية عبر خاصية الملف، أو خيار الوصل، أو بواسطة أمر إزالة التجزئة (defrag). يمكنك الحصول على نقطة وصل btrfs واحدة تحتوي على بعض الملفات غير المضغوطة، وبعضها مضغوط بـ LZO، وبعضها بـ ZLIB، على سبيل المثال (على الرغم من أنك قد لا ترغب في ذلك، إلا أنه مدعوم).

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

يمكن تمييز الخوارزميات على النحو التالي فيما يتعلق بمقايضات السرعة/النسبة:

ZLIB

أبطأ، ونسبة ضغط أعلى
المستويات: من 1 إلى 9، وتُخطط مباشرة، المستوى المبدئي هو 3
توافقية جيدة مع الإصدارات السابقة

LZO

ضغط وإلغاء ضغط أسرع من ZLIB، ونسبة ضغط أسوأ، ومصمم ليكون سريعًا
لا توجد مستويات
توافقية جيدة مع الإصدارات السابقة

ZSTD

ضغط يضاهي ZLIB مع سرعات ضغط/إلغاء ضغط أعلى ونسبة مختلفة
المستويات: -15..15، وتُخطط مباشرة، والمبدئي هو 3
الدعم منذ 4.14
المستويات 1..15 مدعومة منذ 5.1
المستويات -15..-1 مدعومة منذ 6.15

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

كيفية تفعيل الضغط¶

عادة يمكن تمكين الضغط على كامل نظام ملفات، ومحددًا لنقطة الوصل. لاحظ أن خيارات وصل الضغط مشتركة بين جميع عمليات الوصل لنفس نظام ملفات، سواء كانت وصلات ربط (bind mounts) أو وصلات مجلدات فرعية. يرجى الرجوع إلى قسم MOUNT OPTIONS في btrfs(5).

$ mount -o compress=zstd /dev/sdx /mnt

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

$ btrfs filesystem defrag -czstd file

سيبدأ الأمر أعلاه في إزالة تجزئة الملف file بأكمله وتطبيق الضغط، بغض النظر عن خيار الوصل. يمكن أيضًا تحديد مستوى الضغط باستخدام المعطى --level أو -L بدءًا من الإصدار 6.14. خوارزمية الضغط ليست دائمة وتنطبق فقط على أمر إزالة التجزئة، وبالنسبة لأي كتابات أخرى تُطبق إعدادات الضغط الأخرى.

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

$ chattr +c file
$ btrfs property set file compression zstd

يستخدم الأمر الأول الواجهة الموروثة لسمات الملفات المأخوذة من نظام ملفات ext2 وهي ليست مرنة، لذا يُضبط ضغط zlib مبدئيًا. بينما يضبط الأمر الآخر خاصية على الملف باستخدام الخوارزمية المحددة. (ملاحظة: تعيين المستوى بهذه الطريقة لم يُطبق بعد.)

مستويات الضغط¶

أُضيف دعم المستويات لـ ZLIB في v4.14، ولا يدعم LZO المستويات (إذ يوفر تطبيق النواة مستوى واحدًا فقط)، وأُضيف دعم مستويات ZSTD في v5.1 والمستويات السالبة في v6.15.

ثمة 9 مستويات مدعومة لـ ZLIB (من 1 إلى 9)، وتُخطط بنسبة 1:1 من خيار الوصل إلى المستوى المحدد للخوارزمية. المستوى المبدئي هو 3، والذي يوفر نسبة ضغط جيدة ومعقولة ولا يزال سريعًا بشكل معقول. إن الاختلاف في مكاسب الضغط للمستويات 7 و 8 و 9 متقارب ولكن المستويات الأعلى تستغرق وقتًا أطول.

يتضمن دعم ZSTD المستويات من -15 إلى 15، وهو جزء من النطاق الكامل الذي يوفره ZSTD. المستويات من -15 إلى -1 تعمل بالوقت الحقيقي بنسبة ضغط أسوأ، والمستويات من 1 إلى 3 قريبة من الوقت الحقيقي مع ضغط جيد، والمستويات من 4 إلى 8 أبطأ مع ضغط محسّن، والمستويات من 9 إلى 15 تحاول بجهد أكبر على الرغم من أن الحجم الناتج قد لا يتحسن بشكل ملحوظ. تتطلب المستويات الأعلى أيضًا ذاكرة أكبر وبما أنها تحتاج إلى معالجة أكبر فإن أداء النظام يتأثر.

المستوى 0 يعين دائمًا إلى المبدئي. لا يؤثر مستوى الضغط على التوافق.

استثناءات¶

أي ملف عُدل بواسطة استدعاء النظام fallocate سيُستثنى دائمًا من الضغط حتى لو استُخدم خيار الوصل force-compress.

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

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

بيانات غير قابلة للضغط¶

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

إذا حُدد ملف على أنه غير قابل للضغط، يُعين علم (NOCOMPRESS) ويكون لزجًا. لن يُجرى الضغط على هذا الملف ما لم يكن مفروضًا. يمكن أيضًا تعيين العلم بواسطة chattr +m (منذ e2fsprogs 1.46.2) أو بواسطة خصائص بالقيمة no أو none. ستعيده القيمة الفارغة إلى المبدئي المعمول به حاليًا في نظام الملفات الموصول.

هناك طريقتان لاكتشاف البيانات غير القابلة للضغط:

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

$ lsattr file
---------------------m file

لا يُوصى بفرض الضغط، فمن المفترض أن تقرر الاستدلالات ذلك، كما تكتشف خوارزميات الضغط داخليًا البيانات غير القابلة للضغط أيضًا.

استدلالات ما قبل الضغط¶

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

تعتمد الاختبارات التي تُجرى على ما يلي: أخذ عينات البيانات، واكتشاف الأنماط المتكررة الطويلة، وتواتر البايت، وإنتروبيا شانون.

التوافقية¶

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

ستتراجع قراءات الإدخال والإخراج المباشرة للبيانات المضغوطة دائمًا إلى القراءات المخزنة مؤقتًا.

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

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

أُضيفت خوارزميات الضغط بمرور الوقت لذا ينبغي أيضًا مراعاة توافق الإصدارات، إلى جانب الأدوات الأخرى التي قد تصل إلى البيانات المضغوطة مثل محملات الإقلاع.

واجهة SYSFS¶

يحتوي Btrfs على واجهة sysfs لتوفير عناصر تحكم إضافية.

المسار ذو المستوى الأعلى هو /sys/fs/btrfs/، ومخطط الدليل الرئيس هو التوالي:

المسار النسبي	الوصف	الإصدار
features/	كل الميزات المدعومة	3.14
<UUID>/	UUID لنظام الملفات الموصول	3.14
<UUID>/allocation/	معلومات تخصيص المساحة	3.14
<UUID>/bdi/	معلومات الجهاز الخلفي (الكتابة الخلفية)	5.9
<UUID>/devices/<DEVID>/	وصلة رمزية إلى sysfs الخاص بكل جهاز كتلي	5.6
<UUID>/devinfo/<DEVID>/	معلومات محددة لـ Btrfs لكل جهاز	5.6
<UUID>/discard/	إحصائيات ومعلمات الإهمال	6.1
<UUID>/features/	ميزات نظام الملفات	3.14
<UUID>/qgroups/	معلومات qgroup العامة	5.9
<UUID>/qgroups/<LEVEL>_<ID>/	معلومات لكل qgroup	5.9

بالنسبة للدليل /sys/fs/btrfs/features/، يعني كل ملف ميزة مدعومة في النواة الحالية. معظم الملفات لها القيمة 0. خلاف ذلك يعتمد الأمر على الملف، حيث تعني القيمة 1 عادةً أنه يمكن تفعيل الميزة في نظام ملفات موصول.

بالنسبة للدليل /sys/fs/btrfs/<UUID>/features/، يعني كل ملف ميزة مفعلة في نظام الملفات الموصول.

تتشارك الميزات نفس الاسم في قسم FILESYSTEM FEATURES.

UUID¶

الملفات في الدليل /sys/fs/btrfs/<UUID>/ هي:

bg_reclaim_threshold

(قراءة وكتابة، منذ: 5.19)

نسبة المساحة المستخدمة من إجمالي مساحة الجهاز لبدء المطالبة الآلية بمجموعة الكتل. في الغالب للأجهزة المقسمة إلى مناطق.

checksum

(قراءة فقط، منذ: 5.5)

المجموع التحققي المستخدم لنظام ملفات الموصول. يشمل هذا كلاً من نوع المجموع التحققي (انظر قسم CHECKSUM ALGORITHMS) وبرنامج التشغيل المطبق (يظهر غالبًا ما إذا كان مسرعًا عتاديًا).

clone_alignment

(قراءة فقط، منذ: 3.16)

محاذاة البايتات لعمليات التحكم في الإدخال والإخراج clone و dedupe.

commit_stats

(قراءة وكتابة، منذ: 6.0)

إحصائيات الأداء لإيداع معاملات btrfs منذ الوصل الأول. في الغالب لأغراض تنقيح الأخطاء.

ستؤدي الكتابة في هذا الملف إلى إعادة تعيين الحد الأقصى لمدة الإيداع (max_commit_ms) إلى 0. يبدو الملف كالتالي:

commits 70649
last_commit_ms 2
max_commit_ms 131
total_commit_ms 170840

commits - عدد إيداعات المعاملات منذ الوصل الأول
last_commit_ms - المدة بالملي ثانية لآخر إيداع
max_commit_ms - أقصى وقت استغرقه إيداع المعاملة منذ الوصل الأول أو آخر إعادة تعيين
total_commit_ms - مجموع أوقات إيداع كل المعاملات

exclusive_operation: (قراءة فقط، منذ: 5.10)
يعرض العملية الحصرية الجارية. تحقق من قسم FILESYSTEM EXCLUSIVE OPERATIONS للتفاصيل.
generation: (قراءة فقط، منذ: 5.11)
يظهر جيل نظام الملفات الموصول.
label: (قراءة وكتابة، منذ: 3.14)
يظهر اللصيقة الحالية لنظام الملفات الموصول.
metadata_uuid: (قراءة فقط، منذ: 5.0)
يظهر UUID للبيانات الوصفية لنظام الملفات الموصول. تحقق من ميزة metadata_uuid لمزيد من التفاصيل.
nodesize: (قراءة فقط، منذ: 3.14)
يظهر حجم العقدة لنظام الملفات الموصول.
quota_override: (قراءة وكتابة، منذ: 4.13)
يظهر حالة تجاوز الحصص النسبية الحالية. 0 تعني عدم تجاوز الحصص النسبية. 1 تعني تجاوز الحصص النسبية، حيث يمكن للحصة تجاهل إعدادات الحدود الحالية.
read_policy: (قراءة وكتابة، منذ: 5.11)
يظهر سياسة الموازنة الحالية للقراءات. حاليًا يُدعم pid فقط (الموازنة باستخدام قيمة معرف العملية (pid)). تتوفر المزيد من سياسات الموازنة في البنيات التجريبية، وتحديدًا round-robin.
sectorsize: (قراءة فقط، منذ: 3.14)
يظهر حجم القطاع لنظام الملفات الموصول.
temp_fsid: (قراءة فقط، منذ 6.7)
يشير إلى أن نظام الملفات هذا قد عُين له معرف نظام ملفات (FSID) مؤقت عند وقت الوصل، مما يجعل من الممكن وصل أجهزة بنفس الـ FSID.

UUID/allocations¶

الملفات والأدلة في الدليل /sys/fs/btrfs/<UUID>/allocations هي:

global_rsv_reserved: (قراءة فقط، منذ: 3.14)
البايتات المستخدمة من الحجز العام.
global_rsv_size: (قراءة فقط، منذ: 3.14)
الحجم الإجمالي للحجز العام.
data/, metadata/ and system/ directories: (قراءة فقط، منذ: 5.14)
محاسبة معلومات المساحة لأنواع مجموعات الكتل الثلاثة.

UUID/allocations/{data,metadata,system}¶

الملفات في الدليل /sys/fs/btrfs/<UUID>/allocations/data,metadata,system هي:

bg_reclaim_threshold

(قراءة وكتابة، منذ: 5.19)

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

bytes_*

(RO)

قيم هياكل البيانات المقابلة لنوع مجموعة الكتل والتشكيلة المعطاة والتي تُستخدم داخليًا وقد تتغير بسرعة اعتمادًا على الحمل.

القائمة الكاملة: bytes_may_use, bytes_pinned, bytes_readonly, bytes_reserved, bytes_used, bytes_zone_unusable

chunk_size

(قراءة وكتابة، منذ: 6.0)

يظهر حجم القطعة. يمكن تغييره للبيانات والبيانات الوصفية (بشكل مستقل) ولا يمكن تعيينه لنوع مجموعة كتل النظام. لا يمكن تعيينه للأجهزة المقسمة إلى مناطق لأنه يعتمد على حجم منطقة الجهاز الثابتة. الحد الأقصى هو 10% من حجم نظام الملفات، ويجب أن تكون القيمة مضاعفًا لـ 256 ميجابايت (256MiB) وأكبر من 0.

size_classes

(قراءة فقط، منذ: 6.3)

أعداد مجموعات الكتل لفئات معينة بناءً على الاستدلالات التي تقيس طول المدى، والعمر، والتجزؤ.

none 136
small 374
medium 282
large 93

UUID/bdi¶

وصلة رمزية إلى دليل sysfs لمعلومات الجهاز الخلفي (BDI)، والتي تتعلق بعملية الكتابة الخلفية والبنية التحتية لها.

UUID/devices¶

الملفات في الدليل /sys/fs/btrfs/<UUID>/devices هي وصلات رمزية تُسمى باسم عقد الأجهزة (مثل sda، dm-0) وتؤشر إلى دليل sysfs الخاص بها.

UUID/devinfo¶

يحتوي الدليل على أدلة فرعية تُسمى بمعرفات الأجهزة (قيم رقمية). يحتوي كل دليل فرعي على معلومات حول جهاز الـ devid المعطى.

UUID/devinfo/DEVID¶

الملفات في الدليل /sys/fs/btrfs/<UUID>/devinfo/<DEVID> هي:

error_stats:: (قراءة فقط، منذ: 5.14)
يعرض إحصائيات الجهاز لهذا الجهاز، وهو مطابق للأمر btrfs device stats (btrfs-device(8)).

write_errs 0
read_errs 0
flush_errs 0
corruption_errs 0
generation_errs 0

fsid:: (قراءة فقط، منذ: 5.17)
يظهر معرف نظام الملفات (fsid) الذي ينتمي إليه الجهاز. يمكن أن يكون مختلفًا عن الـ UUID إذا كان جهازًا بذررًا.
in_fs_metadata: (قراءة فقط، منذ: 5.6)
يظهر ما إذا كان قد عُثر على الجهاز. ينبغي أن يكون دائمًا 1، لأنه إذا تحول إلى 0، فسيُزال دليل DEVID آليًا.
missing: (قراءة فقط، منذ: 5.6)
يظهر ما إذا كان الجهاز يُعتبر مفقودًا بواسطة وحدة النواة.
replace_target: (قراءة فقط، منذ: 5.6)
يظهر ما إذا كان الجهاز هو الهدف المستبدل. إذا لم تكن هناك عملية استبدال جهاز جارية، تكون هذه القيمة 0.
scrub_speed_max: (قراءة وكتابة، منذ: 5.14)
يظهر حد سرعة التنظيف لهذا الجهاز. الوحدة هي بايت/ثانية. 0 تعني عدم وجود حد. يمكن ضبط القيمة ولكنها ليست دائمة.
writeable: (قراءة فقط، منذ: 5.6)
يظهر ما إذا كان الجهاز قابلاً للكتابة.

UUID/qgroups¶

الملفات في الدليل /sys/fs/btrfs/<UUID>/qgroups/ هي:

enabled

(قراءة فقط، منذ: 6.1)

يظهر ما إذا كان qgroup مفعلاً. أيضًا، إذا كان qgroup معطلاً، فسيُزال دليل qgroups آليًا.

inconsistent

(قراءة فقط، منذ: 6.1)

يُبين ما إذا كانت أرقام qgroup غير متسقة. إذا كانت القيمة 1، فيُوصى بإجراء إعادة فحص (rescan) لـ qgroup.

drop_subtree_threshold

(قراءة وكتابة، منذ: 6.1)

يُبين عتبة إسقاط الشجرة الفرعية لوسم qgroup آليًا بأنه غير متسق.

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

القيمة المبدئية هي 3، مما يعني أن الأشجار ذات الارتفاع المنخفض ستُحسب بشكل صحيح لأن هذا سريع بما يكفي. كانت القيمة 8 حتى الإصدار 6.13 حيث لم يكن بإمكان أي إسقاط لشجرة فرعية إطلاق إعادة فحص qgroup، مما جعلها أقل فائدة.

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

UUID/qgroups/LEVEL_ID¶

الملفات الموجودة في كل دليل /sys/fs/btrfs/<UUID>/qgroups/<LEVEL>_<ID>/ هي:

exclusive: (قراءة فقط، منذ: 5.9)
يُبين البايتات المملوكة حصريًا لـ qgroup.
limit_flags: (قراءة فقط، منذ: 5.9)
يُبين القيمة الرقمية لأعلام القيود. إذا كانت 0، فهذا يعني عدم وجود أي قيد وضمني.
max_exclusive: (قراءة فقط، منذ: 5.9)
يُبين القيود المفروضة على البايتات المملوكة حصريًا.
max_referenced: (قراءة فقط، منذ: 5.9)
يُبين القيود المفروضة على البايتات المُشار إليها.
referenced: (قراءة فقط، منذ: 5.9)
يُبين البايتات المُشار إليها لـ qgroup.
rsv_data: (قراءة فقط، منذ: 5.9)
يُبين البايتات المحجوزة للبيانات.
rsv_meta_pertrans: (قراءة فقط، منذ: 5.9)
يُبين البايتات المحجوزة للميانات الوصفية الخاصة بكل معاملة.
rsv_meta_prealloc: (قراءة فقط، منذ: 5.9)
يُبين البايتات المحجوزة للميانات الوصفية المخصصة مسبقًا.

UUID/discard¶

الملفات الموجودة في الدليل /sys/fs/btrfs/<UUID>/discard/ هي:

discardable_bytes: (قراءة فقط، منذ: 6.1)
يُبين كمية البايتات التي يمكن التخلص منها في وضع الإسقاط غير المتزامن (async discard) ووضع عدم الإسقاط (nodiscard).
discardable_extents: (قراءة فقط، منذ: 6.1)
يُبين عدد الامتدادات (extents) التي ينبغي التخلص منها في وضع الإسقاط غير المتزامن ووضع عدم الإسقاط.
discard_bitmap_bytes: (قراءة فقط، منذ: 6.1)
يُبين كمية البايتات المُسقطة من البيانات المتتبعة كخرائط بتات (bitmaps).
discard_extent_bytes: (قراءة فقط، منذ: 6.1)
يُبين كمية الامتدادات المُسقطة من البيانات المتتبعة كخرائط بتات (bitmaps).
discard_bytes_saved: (قراءة فقط، منذ: 6.1)
يُبين كمية البايتات التي أُعيد تخصيصها دون أن يُتخلص منها.
kbps_limit: (قراءة وكتابة، منذ: 6.1)
حد قابل للضبط للكيلوبايتات في الثانية الصادرة كعمليات إدخال وإخراج للإسقاط في وضع الإسقاط غير المتزامن.
iops_limit: (قراءة وكتابة، منذ: 6.1)
حد قابل للضبط لعدد عمليات إدخال وإخراج الإسقاط التي تُصدر في وضع الإسقاط غير المتزامن.
max_discard_size: (قراءة وكتابة، منذ: 6.1)
حد قابل للضبط لحجم طلب إسقاط واحد لعمليات الإدخال والإخراج.

العمليات الحصرية لنظام الملفات¶

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

منذ النواة 5.10، يمكن الحصول على العملية الجاري تشغيلها حاليًا من الملف /sys/fs/UUID/exclusive_operation بالقيم والعمليات التالية:

balance
الموازنة مُوقفة مؤقتًا (منذ 5.17)
device add
device delete
device replace
resize
swapfile activate
none

الإدراج في الصف مدعوم للعديد من الأوامر الفرعية لـ btrfs ليتسنى بدؤها دفعة واحدة ثم تسلسلها.

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

حدود نظام الملفات¶

maximum file name length: 255
تفرض Linux VFS هذا الحد، علمًا بأن بنيات BTRFS قادرة على تخزين أسماء ملفات أطول.
أقصى طول لهدف الوصلة الرمزية: يعتمد على قيمة nodesize، فمن أجل 4KiB يبلغ 3949 بايت، ومن أجل قيم nodesize الأكبر يبلغ 4095 بسبب حد النظام PATH_MAX
قد لا يكون هدف الوصلة الرمزية مسارًا صالحًا، أي أن مكونات اسم المسار يمكن أن تتجاوز الحدود (NAME_MAX)، حيث لا يوجد تحقق من صحة المحتوى عند إنشاء الوصلة عبر symlink(3).
أقصى عدد للعقد الفهرسية (inodes): 264 ولكن يعتمد على مساحة البيانات الوصفية المتاحة نظرًا لأن العقد الفهرسية تُنشأ ديناميكيًا
يمثل كل حجم فرعي فضاء أسماء مستقل للعقد الفهرسية وبالتالي أرقامها، لذا فإن الحد يكون لكل حجم فرعي، وليس لنظام الملفات بأكمله.
أرقام العقد الفهرسية (inode): الرقم الأدنى: 256 (للأحجام الفرعية)، الملفات والمجلدات العادية: 257، الرقم الأقصى: (264 - 256)
تكون أرقام العقد الفهرسية التي يمكن تخصيصها للملفات التي ينشئها المستخدم من كامل فضاء 64 بت باستثناء أول 256 وآخر 256 رقمًا في ذلك النطاق، والتي تكون محجوزة لمعرفات b-tree الداخلية.
أقصى طول للملف: الحد المتأصل في BTRFS هو 264 (16 إكسبي بايت) ولكن الحد العملي في Linux VFS هو 263 (8 إكسبي بايت)
أقصى عدد للأحجام الفرعية: يمكن لمعرفات الأحجام الفرعية أن تصل إلى 248 ولكن عدد الأحجام الفرعية الفعلية يعتمد على مساحة البيانات الوصفية المتاحة
المساحة التي تستهلكها البيانات الوصفية لجميع الأحجام الفرعية، بما في ذلك مسك دفاتر الامتدادات (extents) المشتركة، يمكن أن تكون كبيرة (ميجابايت، جيجابايت). النطاق ليس كامل نطاق 64 بت نظرًا لأن qgroups تستخدم الـ 16 بت العليا لأغراض أخرى.
أقصى عدد للوصلات الصلبة لملف في دليل: 65536 عند تفعيل ميزة extref أثناء mkfs (مبدئي)، وقرابة 100 خلاف ذلك ويعتمد على طول اسم الملف الذي يتسع في عقدة بيانات وصفية واحدة
الحد الأدنى لحجم نظام الملفات: يعتمد الحجم الأدنى لكل جهاز على ميزة mixed-bg، فبدونها (المبدئي) يبلغ حوالي 109 ميجابايت، ومع mixed-bg يبلغ 16 ميجابايت

دعم محمل الإقلاع¶

يمتلك GRUB2 ‏(https://www.gnu.org/software/grub) الدعم الأكثر تقدمًا للإقلاع من BTRFS فيما يتعلق بالميزات.

يمتلك U-Boot ‏(https://www.denx.de/wiki/U-Boot/) دعمًا جيدًا للإقلاع ولكن لم تُطبق جميع ميزات BTRFS، تحقق من التوثيق.

بشكل عام، أول 1MiB على كل جهاز يكون غير مستخدم باستثناء الكتلة الفائقة الرئيسة التي تقع عند الإزاحة 64KiB وتمتد لمسافة 4KiB. الباقي يمكن استخدامه بحرية بواسطة محملات الإقلاع أو لمعلومات النظام الأخرى. لاحظ أن الإقلاع من نظام ملفات على zoned device (جهاز مقسم) غير مدعوم.

سمات الملف¶

يدعم نظام ملفات btrfs تعيين سمات الملفات أو أعلامها. يُرجى ملاحظة وجود واجهات قديمة وجديدة بأسماء مربكة. من شأن القائمة التالية توضيح ذلك:

attributes (السمات): أدوات chattr(1) أو lsattr(1) (عمليات ioctl هي FS_IOC_GETFLAGS و FS_IOC_SETFLAGS)، ونظرًا لأسماء ioctl تسمى السمات أيضًا بالأعلام
xflags: لتمييزها عن السابقة، هي أعلام موسعة ذات بتات قابلة للضبط شبيهة بالسمات ولكنها قابلة للتوسيع وستُضاف بتات جديدة في المستقبل (عمليات ioctl هي FS_IOC_FSGETXATTR و FS_IOC_FSSETXATTR ولكنها ليست مرتبطة بالسمات الموسعة التي تسمى أيضًا xattrs)، لا توجد أداة قياسية لتغيير البتات، وهناك دعم لها في xfs_io(8) كأمر xfs_io -c chattr

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

السمات¶

a

(ملف، دليل، جذر) إضافة فقط، تُكتب الكتابات الجديدة دائمًا في نهاية الملف

A

(ملف، دليل) لا تحديثات لـ atime

c

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

عند تعيينها على دليل، سترث جميع الملفات المنشأة حديثًا هذه السمة. لا يمكن تعيين هذه السمة مع العلامة 'm' في الوقت نفسه.

C

(ملف، دليل، موروث) لا نسخ عند الكتابة، تُجرى تعديلات بيانات الملف في مكانها

عند تعيينها على دليل، سترث جميع الملفات المنشأة حديثًا هذه السمة.

ملاحظة:

بسبب قيود في التنفيذ، لا يمكن تعيين/إلغاء تعيين هذا العلم إلا على الملفات الفارغة.

d: (ملف) no dump، يكون منطقيًا مع أدوات الطرف الثالث مثل dump(8)، وعلى BTRFS يمكن تعيين/إلغاء تعيين السمة ولكن لا تُجرى أي معالجة خاصة أخرى
D: (دليل) synchronous directory updates (تحديثات الدليل المتزامنة)، لمزيد من التفاصيل ابحث في open(2) عن O_SYNC و O_DSYNC
i: (ملف، دليل، جذر) غير قابل للتغيير، لا يُسمح بإجراء تغييرات على بيانات الملف وبياناته الوصفية حتى للمستخدم الجذر طالما كانت هذه السمة معينة (وبالطبع الاستثناء هو إلغاء تعيين السمة)
m: (ملف، دليل) no compression (لا ضغط)، لإيقاف تشغيل الضغط بشكل دائم على الملف المحدد. لن تؤثر أي خيارات وصل للضغط على هذا الملف. (أُضيف الدعم في chattr(1) في الإصدار 1.46.2)
عند تعيينها على دليل، سترث جميع الملفات المنشأة حديثًا هذه السمة. لا يمكن تعيين هذه السمة مع العلامة c في الوقت نفسه.
S: (ملف) synchronous updates (تحديثات متزامنة)، لمزيد من التفاصيل ابحث في open(2) عن O_SYNC و O_DSYNC
V: (ملف، قراءة فقط) تمكين fs-verity على الملف

لا توجد سمات أخرى مدعومة. للقائمة الكاملة يرجى الرجوع إلى صفحة الدليل chattr(1).

XFLAGS¶

هناك تداخل في الأحرف المخصصة للبتات مع السمات، وتشير هذه القائمة إلى ما يوفره xfs_io(8):

i: غير قابل للتغيير، مثل السمة تمامًا
a: إضافة فقط، مثل السمة تمامًا
s: تحديثات تزامنية، مثل السمة S تمامًا
A: لا تحديثات لـ atime، مثل السمة تمامًا
d: لا تفريغ، مثل السمة تمامًا

الوضع المقسم إلى مناطق¶

منذ الإصدار 5.12 يدعم btrfs ما يسمى بـ zoned mode (الوضع المقسم). هذا نسق خاص على القرص واستراتيجية تخصيص/كتابة ملائمة للأجهزة المقسمة. باختصار، يُقسم الجهاز إلى مناطق ذات حجم ثابت ويمكن تحديث كل منطقة بطريقة الإلحاق فقط، أو إعادة تعيينها. وبما أن btrfs لا يحتوي على هياكل بيانات ثابتة، باستثناء الكتل الفائقة، فإن الوضع المقسم يتطلب فقط وضع الكتل بما يتوافق مع قيود الجهاز. يمكنك التعرف على المعمارية بأكملها على https://zonedstorage.io .

تُسمى الأجهزة أيضًا SMR/ZBC/ZNS، في وضع المُدار بواسطة المضيف (host-managed). لاحظ أن ثمة أجهزة تظهر وكأنها غير مقسمة إلى مناطق ولكنها كذلك في الواقع، وهذا هو وضع المُدار بواسطة المحرك (drive-managed) ولن يفيد استخدام الوضع المقسم إلى مناطق في هذه الحالة.

يعتمد حجم المنطقة على الجهاز، والأحجام النموذجية هي 256 ميجابايت أو 1 جيجابايت. وبشكل عام يجب أن يكون الحجم أسًا للعدد اثنين. وتتيح الأجهزة المقسمة والمحاكاة مثل null_blk تعيين أحجام مناطق متنوعة.

المتطلبات والقيود¶

يجب أن تمتلك جميع الأجهزة حجم المنطقة نفسه
أقصى حجم للمنطقة هو 8 جيجابايت
أدنى حجم للمنطقة هو 4 ميجابايت
يُعد خلط الأجهزة المقسمة وغير المقسمة إلى مناطق أمرًا ممكنًا، وتُحاكى كتابات المنطقة، ولكن هذا مخصص للاختبار تحديدًا
تُعالج كتلة الرمز الفوقية بطريقة خاصة وتوجد في مواقع مختلفة عما هي عليه في نظام الملفات غير المقسم إلى مناطق:

الرئيسة: 0B (والمنطقتان التاليتان)
الثانوية: 512 جيجابايت (والمنطقتان التاليتان)
الثالثية: 4 تيرابايت (4096 جيجابايت، والمنطقتان التاليتان)

الميزات غير المتوافقة¶

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

NODATACOW - الكتابة الفوقية في المكان، لا يمكن إنشاء مثل هذه الملفات
fallocate - تخصيص المساحة مسبقًا للكتابة الأولى في المكان
mixed-bg - كتابات غير مرتبة للبيانات والبيانات الوصفية، وإصلاح ذلك يعني استخدام مجموعات كتل منفصلة للبيانات والبيانات الوصفية
الإقلاع - تحتوي المنطقة عند الإزاحة 0 على كتلة الرمز الفوقية، وإعادة تهيئة المنطقة سيؤدي إلى تدمير بيانات محمل الإقلاع

يفتقر الدعم الأولي إلى بعض الميزات ولكنها مخططة:

لا تُدعم سوى التشكيلة single (للبيانات، والبيانات الوصفية) و DUP (للبيانات الوصفية)
fstrim - بسبب الاعتماد على خبيئة المساحة الحرة v1

الكتلة الفائقة¶

كما ذُكر أعلاه، تُعامل الكتلة الفائقة بطريقة خاصة. لضمان الأمان عند الانهيار، يجب أن تحتوي منطقة واحدة على الأقل في موقع معروف على كتلة فائقة صالحة. يُنفذ هذا كمخزن مؤقت حلقي في منطقتين متتاليتين، بدءًا من الإزاحات المعروفة 0B و 512GiB و 4TiB.

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

تعتمد مساحة المساحة المحجوزة للكتلة الفائقة على حجم المنطقة. توجد النسخ الثنائية والثلاثية عند إزاحات بعيدة لأن سعة الأجهزة يُتوقع أن تكون كبيرة، بعشرات التيرابايت. أقصى حجم منطقة مدعوم هو 8GiB، مما يعني على سبيل المثال أن الإزاحة 0-16GiB ستُحجز فقط للكتلة الفائقة على جهاز افتراضي بحجم المنطقة ذاك. هذا فيه هدر للمساحة ولكنه مطلوب لضمان الأمان عند الانهيار.

استصلاح المناطق، وجمع المهملات¶

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

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

الأجهزة¶

العتاد الحقيقي¶

تعلن سلسلة WD Ultrastar 600 عن دعم HM-SMR، أي وضع المناطق المدار من المضيف. هناك وضعان آخران: DA (مدار من الجهاز، لا تُصدر معلومات المناطق إلى النظام)، و HA (مدرك للمضيف، يمكن استخدامه كقرص عادي ولكن الكتابة المقسمة إلى مناطق تحسن الأداء). لا تتوفر العديد من الأجهزة في الوقت الحالي، والمعلومات حول وضع المناطق الدقيق يصعب العثور عليها، تحقق من أوراق البيانات أو المصادر المجتمعية التي تجمع المعلومات من الأجهزة الحقيقية.

ملاحظة: لن يعمل وضع المناطق مع أقراص DM-SMR.

•: Ultrastar® DC ZN540 NVMe ZNS SSD (product brief)

المحاكي: null_blk¶

يوفر المشغل null_blk جهازًا مدعومًا بالذاكرة وهو مناسب للاختبار. هناك بعض الغرائب في إعداد الأجهزة. يجب تحميل الوحدة مع nr_devices=0 وإلا ستنزاح أرقام عقد الأجهزة. يجب وصل configfs عند /sys/kernel/config وتُدار أجهزة null_blk في /sys/kernel/config/nullb. تُسمى عقد الأجهزة مثل /dev/nullb0 وتُرقم بالتسلسل. ملاحظة: قد يختلف اسم الجهاز عن اسم الدليل في sysfs!

الإعداد:

modprobe configfs
modprobe null_blk nr_devices=0

أنشئ جهازًا باسم mydev، بافتراض عدم وجود أجهزة أخرى مٌنشأة مسبقًا، بحجم 2048MiB، وحجم منطقة 256MiB. هناك المزيد من المعاملات القابلة للضبط، وهذا مثال أدنى يأخذ القيم المبدئية:

cd /sys/kernel/config/nullb/
mkdir mydev
cd mydev
echo 2048 > size
echo 1 > zoned
echo 1 > memory_backed
echo 256 > zone_size
echo 1 > power

سينشئ هذا جهازًا باسم /dev/nullb0 وستطابق قيمة الملف index الرقم الأخير من عقدة الجهاز.

أزل الجهاز:

rmdir /sys/kernel/config/nullb/mydev

ثم تابع باستخدام mkfs.btrfs /dev/nullb0، حيث يُكتشف وضع المناطق آليًا.

للتسهيل، هناك سكربت يغلف عمليات إدارة null_blk الأساسية https://github.com/kdave/nullb.git، وتصبح الأوامر المذكورة أعلاه:

nullb setup
nullb create -s 2g -z 256
mkfs.btrfs /dev/nullb0
...
nullb rm nullb0

المحاكي: TCMU runner¶

TCMU هو إطار عمل لمحاكاة أجهزة SCSI في فضاء المستخدم، ويوفر خلفيات متنوعة للتخزين، مع دعم التقسيم أيضًا. يمكن للجهاز المقسم المدعوم بملف توفير خيارات أكثر لسعة تخزين أكبر وحجم منطقة أكبر. يرجى اتباع التعليمات في https://zonedstorage.io/projects/tcmu-runner/ .

التوافق، وعدم التوافق¶

تضبط الميزة بت عدم التوافق (incompat bit) وتتطلب نواة جديدة للوصول إلى نظام الملفات (لكل من القراءة والكتابة)
يجب التعامل مع الكتلة الفائقة بطريقة خاصة، لا تزال هناك 3 نسخ ولكن عند إزاحات مختلفة (0، و 512GiB، و 4TiB) والمنطقتان المتتاليتان هما مخزن مؤقت حلقي للكتل الفائقة، ويتطلب العثور على أحدث نسخة قراءتها من مؤشر الكتابة أو إجراء مسح كامل للمناطق
خلط الأجهزة المقسمة إلى مناطق وغير المقسمة ممكن (تُحاكى المناطق) ولكن يُوصى به للاختبار فقط
خلط أجهزة مقسمة إلى مناطق بأحجام مناطق مختلفة غير ممكن
يجب أن تكون أحجام المناطق من مضاعفات القوة اثنين، وتكون أحجام مناطق الأجهزة الحقيقية مثل 256MiB أو 1GiB، ويُتوقع أحجام أكبر، وأقصى حجم منطقة يدعمه btrfs هو 8GiB

الحالة، والاستقرار، والإبلاغ عن العيوب¶

أُطلق الوضع المقسم في الإصدار 5.12 ولا تزال هناك بعض الحواف الخشنة والحالات الزاوية التي يمكن مواجهتها أثناء الاختبار. يرجى الإبلاغ عن العلل في https://github.com/naota/linux/issues/ .

المراجع¶

•: https://zonedstorage.io

https://zonedstorage.io/projects/libzbc/ -- libzbc هي مكتبة ومجموعة أدوات لمعالجة الأجهزة التي تدعم ZBC/ZAC مباشرة
https://zonedstorage.io/projects/libzbd/ -- تستخدم libzbd واجهة الجهاز الكتلي المقسم الموفرة من النواة بناءً على استدعاءات النظام ioctl()‎

https://hddscan.com/blog/2020/hdd-wd-smr.html -- بعض التفاصيل حول أنواع الأجهزة الدقيقة
https://lwn.net/Articles/853308/ -- Btrfs on zoned block devices (Btrfs على الأجهزة الكتلية المقسمة)
https://www.usenix.org/conference/vault20/presentation/bjorling -- إلحاق المنطقة: طريقة جديدة للكتابة في التخزين المقسم

جهاز التحكم¶

هناك جهاز محرفي خاص /dev/btrfs-control برقمين رئيس وفرعي 10 و 234 (يمكن العثور على الجهاز تحت فئة misc).

$ ls -l /dev/btrfs-control
crw------- 1 root root 10, 234 Jan  1 12:00 /dev/btrfs-control

يقبل الجهاز بعض استدعاءات ioctl التي يمكنها تنفيذ الإجراءات التالية على وحدة نظام الملفات:

مسح الأجهزة بحثًا عن نظام ملفات btrfs (أي لكي تُوصل أنظمة الملفات متعددة الأجهزة آليًا) وتسجيلها في وحدة النواة
مشابه للمسح، ولكنه ينتظر أيضًا حتى تنتهي عملية مسح الأجهزة لنظام ملفات معين
الحصول على الميزات المدعومة (يمكن العثور عليها أيضًا تحت /sys/fs/btrfs/features)

يُنشأ الجهاز عند تهيئة btrfs، إما كوحدة أو كوظيفة مدمجة، ولا يكون له معنى إلا بالارتباط مع ذلك. تشغيل mkfs على سبيل المثال دون تحميل الوحدة لن يسجل الجهاز وسيحذر على الأرجح من ذلك.

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

# mknod --mode=600 /dev/btrfs-control c 10 234

أو (منذ 5.11) بواسطة أمر تسهيلي

# btrfs rescue create-control-device

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

نظام ملفات بتشكيلات متعددة¶

من الممكن أن يحتوي نظام ملفات btrfs على تشكيلات مجموعات كتل متعددة من النوع نفسه. قد يحدث هذا عند مقاطعة تحويل التشكيلة باستخدام مرشحات الموازنة (انظر btrfs-balance(8)). تُجري بعض أوامر btrfs اختبارًا لاكتشاف هذا النوع من الحالات وتطبع تحذيرًا مثل هذا:

WARNING: Multiple block group profiles detected, see 'man btrfs(5)'.
WARNING:   Data: single, raid1
WARNING:   Metadata: single, raid1

قد تبدو المخرجات المقابلة للأمر btrfs filesystem df كالتالي:

WARNING: Multiple block group profiles detected, see 'man btrfs(5)'.
WARNING:   Data: single, raid1
WARNING:   Metadata: single, raid1
Data, RAID1: total=832.00MiB, used=0.00B
Data, single: total=1.63GiB, used=0.00B
System, single: total=4.00MiB, used=16.00KiB
Metadata, single: total=8.00MiB, used=112.00KiB
Metadata, RAID1: total=64.00MiB, used=32.00KiB
GlobalReserve, single: total=16.25MiB, used=0.00B

هناك أكثر من سطر للنوع Data و Metadata، بينما التشكيلات هي single و RAID1.

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

في المثال أعلاه، بدأ نظام الملفات كجهاز فردي وتشكيلة مجموعات كتل single. ثم أُضيف جهاز آخر، متبوعًا بموازنة مع convert=raid1 ولكنها لم تنتهِ لسبب ما. إعادة تشغيل الموازنة مع convert=raid1 ستستأنف وتنتهي بنظام ملفات تكون جميع تشكيلات مجموعات الكتل فيه هي RAID1.

ملاحظة:

إذا كنت معتادًا على مرشحات الموازنة، يمكنك استخدام convert=raid1,profiles=single,soft، والذي سيأخذ التشكيلات single غير المحولة فقط ويحولها إلى raid1. قد يسرع هذا التحويل لأنه لن يحاول إعادة كتابة تشكيلات raid1 المحولة بالفعل.

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

اختيرت الأوامر التي تطبع التحذير بحيث تلفت انتباه المستخدم عندما تتغير حالة نظام الملفات في هذا الصدد. وهي: device add، و device delete، و balance cancel، و balance pause. الأوامر التي تبلغ عن استخدام المساحة هي: filesystem df، و device usage. ويوفر الأمر filesystem usage سطرًا في الملخص العام:

Multiple profiles:                 yes (data, metadata)

جهاز البذر¶

تتيح آلية النسخ عند الكتابة (COW) والأجهزة المتعددة تحت غطاء واحد مفهومًا مثيرًا للاهتمام، يُسمى جهاز البذر (seeding device): توسيع نظام ملفات للقراءة فقط على جهاز بجهاز آخر يلتقط جميع عمليات الكتابة. على سبيل المثال، تخيل صورة ذهبية غير قابلة للتغيير لنظام تشغيل معززة بجهاز آخر يسمح باستخدام البيانات من الصورة الذهبية والتشغيل العادي. نشأت هذه الفكرة في الأقراص المضغوطة (CD-ROMs) مع نظام التشغيل الأساسي والسماح باستخدامها للأنظمة الحية، ولكن هذا أصبح مهجورًا. توجد تقنيات توفر وظائف مماثلة، مثل unionmount، أو overlayfs أو لقطة صورة qcow2.

يبدأ جهاز البذر كنظام ملفات عادي، وبمجرد أن تصبح المحتويات جاهزة، يُستخدم الأمر btrfstune -S 1 لوسمه كجهاز بذر. لن يسمح وصل هذا الجهاز بأي كتابات، باستثناء إضافة جهاز جديد بواسطة btrfs device add. بعد ذلك يمكن إعادة وصل نظام الملفات كقراءة وكتابة.

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

ملاحظة:

قبل نواة v6.17، كان من الممكن وصل جهاز البذر بشكل مستقل إلى جانب أنظمة الملفات النابتة (sprouted). ولكن منذ النواة 6.17، لا يمكن وصل جهاز البذر إلا إما من خلال نظام ملفات نابت، أو جهاز البذر نفسه، وليس كلاهما في نفس الوقت.

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

بمجرد وصل جهاز البذر، فإنه يحتاج إلى الجهاز القابل للكتابة. بعد إضافته، فإن فصله ووصله بـ umount /path; mount /dev/writable /path أو إعادة وصله للقراءة والكتابة بـ remount -o remount,rw يجعل نظام الملفات عند /path جاهزًا للاستخدام.

ملاحظة:

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

أُصلح ذاك العيب في النواة 5.11 والنوى الأحدث.

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

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

مثال على كيفية إنشاء جهاز بذر واحد واستخدامه:

# mkfs.btrfs /dev/sda
# mount /dev/sda /mnt/mnt1
... fill mnt1 with data
# umount /mnt/mnt1
# btrfstune -S 1 /dev/sda
# mount /dev/sda /mnt/mnt1
# btrfs device add /dev/sdb /mnt/mnt1
# umount /mnt/mnt1
# mount /dev/sdb /mnt/mnt1
... /mnt/mnt1 is now writable

الآن يمكن استخدام /mnt/mnt1 بشكل عادي. يمكن وصل الجهاز /dev/sda مجددًا مع جهاز آخر قابل للكتابة:

# mount /dev/sda /mnt/mnt2
# btrfs device add /dev/sdc /mnt/mnt2
# umount /mnt/mnt2
# mount /dev/sdc /mnt/mnt2
... /mnt/mnt2 is now writable

يمكن فك ارتباط الجهاز القابل للكتابة (الملف: /dev/sdb) عن جهاز البذر واستخدامه بشكل مستقل:

# btrfs device delete /dev/sda /mnt/mnt1

بما أن المحتويات نشأت في جهاز البذر، فمن الممكن تحويل /dev/sdb إلى جهاز بذر مجددًا وتكرار العملية برمتها.

بضع نقاط تجب ملاحظتها:

يُوصى باستخدام جهاز واحد فقط لجهاز البذر، يعمل هذا مع الأجهزة المتعددة ولكن يجب استخدام التشكيلة single لإنجاح عملية حذف جهاز البذر
تدعم تشكيلات مجموعات الكتل single و dup حالات الاستخدام أعلاه
تُنسخ اللصيقة من جهاز البذر ويمكن تغييرها بواسطة btrfs filesystem label
يحصل كل وصل جديد لجهاز البذر على معرف UUID عشوائي جديد
يمكن استبدال umount /path; mount /dev/writable /path بـ mount -o remount,rw /path ولكنه لن يستصلح مساحة الأحجام الفرعية المحذوفة حتى يُوصل جهاز البذر قراءة وكتابة مجددًا قبل جعله جهاز بذر مرة أخرى

أجهزة البذر المتسلسلة¶

رغم أنه غير موصى به وهو حالة استخدام غامضة وغير مختبرة، فإن تسلسل أجهزة البذر ممكن. في المثال الأول، يمكن تحويل الجهاز القابل للكتابة /dev/sdb إلى جهاز بذر آخر مجددًا، معتمدًا على جهاز البذر غير المتغير /dev/sda. ثم باستخدام /dev/sdb كجهاز بذر رئيس يمكن تمديده بجهاز آخر قابل للكتابة، وليكن /dev/sdd، ويستمر الأمر كما كان قبل كبنية شجرية بسيطة على الأجهزة.

# mkfs.btrfs /dev/sda
# mount /dev/sda /mnt/mnt1
... fill mnt1 with data
# umount /mnt/mnt1
# btrfstune -S 1 /dev/sda
# mount /dev/sda /mnt/mnt1
# btrfs device add /dev/sdb /mnt/mnt1
# mount -o remount,rw /mnt/mnt1
... /mnt/mnt1 is now writable
# umount /mnt/mnt1
# btrfstune -S 1 /dev/sdb
# mount /dev/sdb /mnt/mnt1
# btrfs device add /dev/sdc /mnt
# mount -o remount,rw /mnt/mnt1
... /mnt/mnt1 is now writable
# umount /mnt/mnt1

ونتيجة لذلك لدينا:

sda هو جهاز بذر فردي، بمحتوياته الأولية
sdb هو جهاز بذر ولكنه يتطلب sda، والمحتويات هي من الوقت الذي جُعل فيه sdb جهاز بذر، أي محتويات sda مع أي تغييرات لاحقة
sdc الأخير قابل للكتابة، ويمكن جعله جهاز بذر بنفس الطريقة التي عُمل بها مع sdb، محافظًا على محتوياته ومعتمدًا على sda و sdb

طالما أن أجهزة البذر غير معدلة ومتوفرة، يمكن استخدامها لبدء فرع آخر.

حالة RAID56 والممارسات الموصى بها¶

توفر ميزة RAID56 توزيع البيانات (striping) والتكافؤ (parity) عبر عدة أجهزة، تمامًا مثل RAID5/6 التقليدي. هناك بعض العيوب في التنفيذ والتصميم التي تجعلها غير موثوقة في بعض الحالات النادرة و لا ينبغي استخدام الميزة في بيئات الإنتاج، بل للتقييم أو الاختبار فقط. الأمان عند انقطاع الطاقة للبيانات الوصفية مع RAID56 ليس 100%.

البيانات الوصفية¶

لا تستخدم raid5 ولا raid6 للبيانات الوصفية. استخدم raid1 أو raid1c3 على التوالي.

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

نمط تخصيص المساحة واستهلاكها مختلف (على سبيل المثال على N من الأجهزة): بالنسبة إلى raid5 كمثال، تُحجز كتلة بحجم 1GiB على كل جهاز، بينما مع raid1 تُخزن كل كتلة بحجم 1GiB على جهازين. استهلاك كل 1GiB من البيانات الوصفية المستخدمة يكون حينها N * 1GiB مقابل 2 * 1GiB. استخدام raid1 هو أيضًا أكثر ملائمة للموازنة/التحويل إلى تشكيلة أخرى نظرًا لمتطلباته الأقل في مساحة الكتل المتاحة.

الدعم المفقود/غير الكامل¶

عندما يكون RAID56 على نفس نظام الملفات مع تشكيلات raid مختلفة، يكون تقرير المساحة غير دقيق، مثل مخرجات df، أو btrfs filesystem df، أو btrfs filesystem usage. عندما تكون هناك تشكيلة واحدة فقط لكل نوع مجموعة كتل (مثل RAID5 للبيانات) يكون التقرير دقيقًا.

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

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

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

GLOSSARY¶

المصطلحات المكتوبة بخط مائل تظهر أيضًا في مسرد المصطلحات هذا.

allocator: عادةً ما يُقصد بـ المخصِّص مخصِّص الكتل، أي المنطق البرمجي داخل نظام الملفات الذي يقرر مكان وضع الكتل المخصصة حديثًا من أجل الحفاظ على قيود عدة (مثل محلية البيانات، وانخفاض التجزئة).
في btrfs، قد يشير المخصِّص أيضًا إلى مخصِّص القطع، أي المنطق الكامن وراء وضع القطع على الأجهزة.
balance: عملية يمكن إجراؤها على نظام ملفات btrfs، على سبيل المثال من خلال الأمر btrfs balance /path. تُمرر الموازنة جميع البيانات في نظام الملفات عبر المخصِص (allocator) مرة أخرى. تهدف رئيسًا إلى إعادة موازنة البيانات في نظام الملفات عبر الأجهزة عند إضافة جهاز أو إزالته. ستُعيد الموازنة توليد النسخ المفقودة لمستويات RAID الزائدة عن الحاجة، في حال فشل أحد الأجهزة. بدءًا من نواة لينكس 3.3، يمكن جعل عملية الموازنة انتقائية بشأن أجزاء نظام الملفات التي تُعاد كتابتها باستخدام المرشحات.
barrier: تعليمات للجهاز العتادي الأساس لضمان كتابة كل شيء قبل الحائل (barrier) فعليًا على وحدة التخزين الدائمة قبل أي شيء بعده. تُستخدم في نهج النسخ عند الكتابة الخاص بنظام btrfs لضمان اتساق نظام الملفات.
block: قطعة تخزين واحدة متصلة ماديًا ومنطقيًا على جهاز، بحجم 4K مثلًا. يُشار إليها في بعض السياقات أيضًا باسم القطاع (sector)، رُغم تفضيل مصطلح الكتلة.
مجموعة الكتل: وحدة تخصيص المساحة في btrfs. تُرتّب مجموعة الكتل على القرص بواسطة مخصِّص btrfs، وتتكون من قطعة واحدة أو أكثر من القطع، بحيث تُخزن كل قطعة على جهاز مختلف. يعتمد عدد القطع المستخدمة في مجموعة كتل على مستوى RAID الخاص بها.
B-tree: بنية بيانات التخزين الأساسية المستخدمة في btrfs. باستثناء الكتل الفائقة (superblocks)، تُخزن جميع البيانات الوصفية لـ btrfs في شجرة من أشجار B-trees العدة على القرص. تُخزن أشجار B-trees أزواجًا من المفاتيح/العناصر. وبينما تُستخدم التعليمات البرمجية نفسها لتهيئة جميع أشجار B-trees، إلا أن هناك فئات مختلفة قليلاً منها. ويشير الاسم btrfs إلى استخدامه لأشجار B-trees.
btrfsck, fsck, btrfs-check: أداة في حزمة btrfs-progs تفحص نظام ملفات مفصول (دون اتصال) وتبلغ عن أي أخطاء تجدها في بنيات نظام الملفات. تعمل الأداة مبدئيًا في وضع القراءة فقط لأن إصلاح الأخطاء ينطوي على خطورة محتملة. انظر أيضًا scrub.
btrfs-progs: أدوات وضع المستخدم لإدارة الميزات الخاصة بـ btrfs. تُصان في http://github.com/kdave/btrfs-progs.git . الواجهة الرئيسة لميزات btrfs هي الأداة المستقلة btrfs، على الرغم من أن الأدوات الأخرى مثل mkfs.btrfs و btrfstune تعد أيضًا جزءًا من btrfs-progs.
chunk: جزء من مجموعة الكتل. يبلغ حجم القطع إما 1 جيجابايت (للبيانات) أو 256 ميجابايت (لـ البيانات الوصفية)، اعتمادًا على الحجم الإجمالي لنظام الملفات.
chunk tree: طبقة تحتفظ بمعلومات حول المطابقة بين عناوين الكتل المادية والمنطقية. وتُخزن داخل مجموعة النظام.
cleaner: يُشار إليها عادةً في سياق الأحجام الفرعية (subvolumes) المحذوفة. وهي عملية خلفية تزيل البيانات الفعلية بمجرد حذف حجم فرعي. يمكن أن ينطوي التنظيف على الكثير من نشاط الإدخال/الإخراج ووحدة المعالجة المركزية اعتمادًا على التجزئة وكمية البيانات المشتركة مع الأحجام الفرعية الأخرى.
يعالج خيط النواة المنظف (cleaner kernel thread) أيضًا إلغاء التجزئة الناتج عن خيار الوصل autodefrag، وإزالة مجموعات الكتل الفارغة وبعض مهام الإنهاء الأخرى.
copy-on-write, COW: يُعرف أيضًا باسم COW. الطريقة التي يستخدمها btrfs لتعديل البيانات. بدلاً من الكتابة فوق البيانات مباشرة في مكانها، يأخذ btrfs نسخة من البيانات، ويعدلها، ثم يكتب البيانات المعدلة مرة أخرى في موقع مختلف (غير مستخدم) على القرص. ثم يحدث البيانات الوصفية لتعكس الموقع الجديد للبيانات. ومن أجل تحديث البيانات الوصفية، تُعامل كتل البيانات الوصفية المتأثرة بالطريقة نفسها أيضًا. في نظم ملفات COW، تميل الملفات إلى التجزؤ أثناء تعديلها. يُستخدم النسخ عند الكتابة أيضًا في تطبيق اللقطات الفورية (snapshots) و نسخ الروابط المرجعية. يعد نظام ملفات النسخ عند الكتابة، من الناحية النظرية، متسقًا دائمًا، بشرط أن يدعم العتاد الأساس الحوائل (barriers).
default subvolume: الحجم الفرعي في نظام ملفات btrfs الذي يُوصل عند وصل نظام الملفات دون استخدام خيار الوصل subvol=.
device: جهاز كتلي في لينكس، مثل قرص كامل، أو قسم، أو حجم منطقي LVM، أو جهاز حلقي (loopback)، أو جهاز كتلي شبكي. يمكن لنظام ملفات btrfs أن يقع على جهاز واحد أو أكثر.
df: أداة يونكس قياسية للإبلاغ عن مقدار المساحة المستخدمة والحرة في نظام الملفات. لا تعطي الأداة القياسية نتائج دقيقة، ولكن أمر btrfs من حزمة btrfs-progs يحتوي على تهيئة للأداة df تعرض المساحة المتاحة بمزيد من التفصيل. راجع [[FAQ#Why_does_df_show_incorrect_free_space_for_my_RAID_volume.3F|الأسئلة الشائعة]] للحصول على شرح أكثر تفصيلاً لمحاسبة المساحة الحرة في btrfs.
DUP: شكل من أشكال "RAID" يخزن نسختين من كل قطعة بيانات على الجهاز نفسه. هذا يشبه RAID1، ويحمي من الأخطاء على مستوى الكتلة في الجهاز، ولكنه لا يوفر أي ضمانات في حال فشل الجهاز بأكمله. مبدئيًا، يستخدم btrfs تشكيلة DUP للبيانات الوصفية في نظم الملفات ذات الجهاز الواحد.
ENOSPC: رمز خطأ يعيده نظام التشغيل إلى برنامج مستخدم عندما لا يتمكن نظام الملفات من تخصيص بيانات كافية لتلبية طلب المستخدم. في معظم نظم الملفات، يشير هذا إلى عدم وجود مساحة حرة متاحة في نظام الملفات. بسبب متطلبات المساحة الإضافية الناتجة عن سلوك COW في btrfs، يمكن لـ btrfs أحيانًا إعادة الخطأ ENOSPC عندما يكون هناك ظاهريًا (وفقًا لأداة df) كمية كبيرة من المساحة الحرة. هذا يمثل علّة في btrfs، وإذا كان قابلاً للتكرار، فإن استخدام خيار الوصل enospc_debug قد يعطي تقريرًا يساعد مطوري btrfs. راجع [[FAQ#if_your_device_is_large_.28.3E16GiB.29|مدخلة الأسئلة الشائعة]] بشأن المساحة الحرة.
extent: تسلسل متصل من البايتات على القرص يحتوي على بيانات الملف. إنه تمثيل مدمج يتتبع بداية وطول نطاق البايت، لذا فإن المنطق الكامن وراء تخصيص الكتل (التخصيص المؤجل) يسعى جاهدًا لزيادة الطول إلى أقصى حد قبل كتابة الامتدادات (extents) على الأجهزة.
extent buffer: تجريد لكتلة بيانات وصفية لشجرة b-tree تخزن مفاتيح العناصر وبيانات العناصر. البنيات ذات الصلة الأساسية هي كتلة الجهاز المادي وصفحة ذاكرة وحدة المعالجة المركزية.
fallocate: أداة سطر الأوامر في util-linux، واستدعاء نظام، يحجز مساحة في نظام الملفات لملف، دون كتابة أي بيانات ملف فعليًا في نظام الملفات. ستُحول أول كتابة بيانات الامتدادات المحجوزة مسبقًا إلى امتدادات عادية. انظر صفحات الدليل fallocate(1) و fallocate(2) لمزيد من التفاصيل.
filefrag: أداة لعرض عدد الامتدادات في ملف، وبالتالي مقدار التجزئة في الملف. عادةً ما تكون جزءًا من حزمة e2fsprogs في معظم توزيعات لينكس. ورُغم تطويرها في البداية لنظام الملفات ext2، إلا أنها تعمل على Btrfs أيضًا. وتستخدم التحكم بالإدخال والإخراج FIEMAP.
free space cache: يُعرف أيضًا باسم "space cache v1". خبيئة منفصلة تتتبع المساحة الحرة نظراً لأن btrfs يتتبع المساحة المخصصة فقط. المساحة الحرة هي بحكم التعريف أي فجوة بين النطاقات المخصصة. يمكن أن يكون العثور على النطاقات الحرة مكثفًا من حيث الإدخال/الإخراج، لذا تخزن الخبيئة تمثيلاً مكثفاً لها. وتُحدث عند إيداع كل معاملة.
حلت شجرة المساحة الحرة محل خبيئة المساحة الحرة من الإصدار الأول (v1).
free space tree: خليفة خبيئة المساحة الحرة، ويُعرف أيضًا باسم "space cache v2" وهو المبدئي الآن. تُتتبع المساحة الحرة بطريقة أفضل وباستخدام COW على عكس الآلية المخصصة في الإصدار الأول v1.
fsync: في أنظمة تشغيل يونكس والأنظمة الشبيهة بيونكس (والتي يعد لينكس من أواخرها)، يتسبب استدعاء النظام fsync(2) في دفع جميع تغييرات البيانات المخزنة مؤقتًا والمتعلقة بمواصف الملف إلى الجهاز الكتلي الأساسي. عند تعديل ملف على نظام تشغيل حديث، لا تُكتب التغييرات عمومًا إلى القرص فورًا بل تُخزن تلك التغييرات مؤقتًا في الذاكرة لأسباب تتعلق بالأداء، ويتسبب استدعاء fsync(2) في كتابة أي تغييرات في الذاكرة إلى القرص.
generation: عداد داخلي يُحدث مع كل معاملة. عند كتابة كتلة بيانات وصفية (باستخدام النسخ عند الكتابة)، يُخزن الجيل الحالي في الكتلة، بحيث يمكن تحديد الكتل الحديثة جدًا (وبالتالي يحتمل أن تكون غير متسقة).
key: صف (tuple) ثابت الحجم يُستخدم لتحديد العناصر وفرزها في شجرة B-tree. ينقسم المفتاح إلى 3 أجزاء: objectid، و type، و offset. يشير حقل type إلى كيفية استخدام كل من الحقلين الآخرين، وما يمكن توقعه في العنصر.
item: بنية متغيرة الحجم تُخزن في أوراق شجرة B-tree. تحتفظ العناصر بأنواع مختلفة من البيانات اعتمادًا على نوع المفتاح.
log tree: شجرة b-tree تتتبع مؤقتًا تحديثات البيانات الوصفية الجارية حتى يتم إيداع المعاملة بالكامل. إنها تحسين للأداء لعملية fsync. تُعاد قراءة السجل المتتبع في الشجرة إذا لم يُفصل نظام الملفات بشكل نظيف.
metadata: بيانات عن البيانات. في btrfs، يشمل ذلك جميع بنيات البيانات الداخلية لنظام الملفات، بما في ذلك بنيات الأدلة، وأسماء الملفات، وأذونات الملفات، والمجاميع التدقيقية (checksums)، وموقع امتدادات كل ملف. تُخزن جميع البيانات الوصفية لـ btrfs في أشجار B-trees.
mkfs.btrfs: الأداة (من حزمة btrfs-progs) لإنشاء نظام ملفات btrfs.
offline: يكون نظام الملفات الذي لم يُوصل دون اتصال (offline). بعض الأدوات (مثل btrfsck) تعمل فقط على نظم الملفات التي دون اتصال. قارن مع متصل.
online: يكون نظام الملفات الموصول متصلاً (online). معظم أدوات btrfs تعمل فقط على نظم الملفات المتصلة. قارن مع دون اتصال.
orphan: ملف لا يزال قيد الاستخدام (مفتوح بواسطة عملية جارية) ولكن أُزيلت جميع مدخلات الدليل الخاصة بهذا الملف.
RAID: فئة من الطرق المختلفة لكتابة بعض البيانات التكرارية الإضافية عبر أجهزة متعددة بحيث إذا فشل جهاز واحد، يمكن إعادة بناء البيانات المفقودة من الأجهزة المتبقية. انظر RAID0، و RAID1، و RAID5، و RAID6، و RAID10، و DUP، و single. تعمل طرق RAID التقليدية عبر أجهزة متعددة متساوية الحجم، بينما يعمل تطبيق RAID في btrfs داخل مجموعات الكتل.
RAID0: شكل من أشكال RAID لا يقدم أي ضمانات لاسترداد الأخطاء، ولكنه يوزع نسخة واحدة من البيانات شريطيًا عبر أجهزة متعددة لأغراض الأداء. حجم الشريطة ثابت عند 64 كيلوبايت حاليًا.
RAID1, RAID1C3, RAID1C4: شكل من أشكال RAID يخزن نسختين/ثلاث/أربع نسخ كاملة من كل قطعة بيانات. تُخزن كل نسخة على جهاز مختلف. يتطلب btrfs جهازين كحد أدنى لاستخدام RAID-1 أو ثلاثة/أربعة أجهزة على التوالي. هذه هي التشكيلة المبدئية لمجموعة الكتل لـ البيانات الوصفية في btrfs على أكثر من جهاز واحد.
RAID5: شكل من أشكال RAID يوزع نسخة واحدة من البيانات شريطيًا عبر أجهزة متعددة، بما في ذلك ما يعادل مساحة جهاز واحد من بيانات التكافؤ (parity) الإضافية. يمكن استخدامه للاسترداد من فشل جهاز واحد.
RAID6: شكل من أشكال RAID يوزع نسخة واحدة من البيانات شريطيًا عبر أجهزة متعددة، بما في ذلك ما يعادل مساحة جهازين من بيانات التكافؤ الإضافية. يمكن استخدامه للاسترداد من فشل جهازين.
RAID10: شكل من أشكال RAID يخزن نسختين كاملتين من كل قطعة بيانات، ويوزع أيضًا كل نسخة شريطيًا عبر أجهزة متعددة لتحسين الأداء.
reflink: يُستخدم عادةً كإشارة إلى نسخة ضحلة من امتدادات الملفات التي تشترك في الامتدادات نفسها حتى حدوث أول تغيير. الملفات ذات الروابط المرجعية (reflinked) (على سبيل المثال عبر الأمر cp) هي ملفات مختلفة ولكنها تشير إلى الامتدادات نفسها، ويُكشف عن أي تغيير وتُنشأ نسخة جديدة من البيانات، مما يحافظ على استقلالية الملفات. يرتبط بذلك استنساخ نطاق الامتداد، والذي يعمل على نطاق معين من الملف.
relocation: عملية نقل مجموعات الكتل داخل نظام الملفات مع الحفاظ على سلامة نظام الملفات واتساقه بالكامل. هذه الوظيفة هي الأساس لميزات الموازنة balance وإزالة الأجهزة.
scrub: أداة فحص نظام ملفات متصلة. تقرأ جميع البيانات والبيانات الوصفية على نظام الملفات، وتتحقق من المجاميع التدقيقية وتستخدم في النهاية النسخ التكرارية من RAID أو DUP لإصلاح أي بيانات/بيانات وصفية تالفة.
seed device: يمكن استخدام جهاز للقراءة فقط كبذرة (seed) لنظام الملفات أو كقالب (مثل قرص مدمج يحتوي على صورة نظام تشغيل). يمكن إضافة أجهزة للقراءة/الكتابة لتخزين التعديلات (باستخدام النسخ عند الكتابة)، وتكون التغييرات على الأجهزة القابلة للكتابة دائمة عبر عمليات إعادة التشغيل. يظل الجهاز الأصلي دون تغيير ويمكن إزالته في أي وقت (بعد توجيه Btrfs لنسخ جميع الكتل المفقودة). يمكن بناء نظم ملفات متعددة للقراءة/الكتابة من البذرة نفسها.
single: تشكيلة مجموعة كتل تخزن نسخة واحدة من كل قطعة بيانات.
snapshot: حجم فرعي يعد نسخة طبق الأصل بأسلوب النسخ عند الكتابة لحجم فرعي آخر. يشترك الحجمان الفرعيان في جميع بياناتهما المشتركة (غير المعدلة)، مما يعني أنه يمكن استخدام اللقطات الفورية للحفاظ على الحالة التاريخية لنظام الملفات بتكلفة منخفضة جدًا. بعد أخذ اللقطة الفورية، يكون للحجم الفرعي الأصلي والقطة الفورية الحالة نفسها: الأصلي لا "يملك" اللقطة، ويمكن حذف أي منهما دون التأثير على الآخر.
subvolume: شجرة من الملفات والأدلة داخل btrfs يمكن وصلها كما لو كانت نظام ملفات مستقلاً. يُنشأ الحجم الفرعي عن طريق أخذ مرجع لجذر حجم فرعي آخر. يحتوي كل نظام ملفات btrfs على حجم فرعي واحد على الأقل، وهو الحجم الفرعي ذو المستوى الأعلى، والذي يحتوي على كل شيء آخر في نظام الملفات. يمكن إنشاء أحجام فرعية إضافية وحذفها باستخدام أداة btrfs. تشترك جميع الأحجام الفرعية في مجمع المساحة الحرة نفسه في نظام الملفات. انظر أيضًا الحجم الفرعي المبدئي.
super block: كتلة بيانات وصفية خاصة تمثل نقطة الوصول الرئيسة لبنيات نظام الملفات. حجمها ثابت وهناك مواقع ثابتة على الأجهزة تُستخدم لاكتشاف نظام الملفات وفتحه. يحدد تحديث الكتلة الفائقة معاملة واحدة. تحتوي الكتل الفائقة على معرف نظام الملفات (UUID)، ونوع المجموع التدقيقي، ومؤشرات الكتل للأشجار الأساسية، والميزات، ومعاملات الإنشاء.
system array: مصطلح تقني للبيانات الوصفية لـ الكتلة الفائقة يصف كيفية تجميع نظام ملفات من أجهزة متعددة، ويخزن معلومات حول القطع والأجهزة المطلوب فحصها/تسجيلها في الوقت الذي يحدث فيه الوصل. يُجرى الفحص بواسطة الأمر btrfs device scan، أو بدلاً من ذلك يمكن تحديد جميع الأجهزة المطلوبة عبر خيار الوصل device=/path.
top-level subvolume: الحجم الفرعي الموجود في أعلى نظام الملفات تمامًا. هذا هو الحجم الفرعي الوحيد الموجود في نظام ملفات btrfs المنشأ حديثًا، وله المعرف الداخلي 5، وبخلاف ذلك يمكن الإشارة إليه بالقيمة 0 (على سبيل المثال ضمن الأمر الفرعي set-default لأداة btrfs).
transaction: مجموعة متسقة من التغييرات. لتجنب توليد كميات كبيرة جدًا من نشاط القرص، يخزن btrfs التغييرات مؤقتًا في ذاكرة الوصول العشوائي (RAM) لمدة تصل إلى 30 ثانية (وأحيانًا أكثر إذا كان نظام الملفات يعاني من نقص في المساحة أو يقوم بالكثير من عمليات fsync)، ثم يكتب (يودع) هذه التغييرات على القرص دفعة واحدة (باستخدام سلوك *النسخ عند الكتابة*). تُسمى فترة التخزين المؤقت هذه معاملة (transaction). تكون هناك معاملة واحدة نشطة فقط على نظام الملفات في أي وقت.
transid: مصطلح بديل لـ الجيل.
writeback: يمكن تعريف الكتابة الخلفية (Writeback) في سياق نواة لينكس بأنها عملية كتابة الذاكرة "المتسخة" (dirty) من خبيئة الصفحات إلى القرص، عند استيفاء شروط معينة (مهلة زمنية، تخطي نسبة معينة من الصفحات المتسخة).

نموذج التخزين، اعتبارات العتاد¶

نموذج التخزين¶

نموذج التخزين هو نموذج يجسد الجوانب المادية الرئيسة لبنية البيانات في مخزن البيانات. نظام الملفات هو البنية المنطقية التي تنظم البيانات فوق جهاز التخزين.

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

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

تُؤخذ الافتراضات التالية حول أجهزة التخزين في الحسبان (مرتبة حسب الأهمية، والأرقام هي للإشارة إليها لاحقًا):

1.: ذرية عمليات القراءة والكتابة للكتل/القطاعات (أصغر وحدة بيانات يقدمها الجهاز للطبقات العليا)
2.: وجود أمر دفع (flush) يوجه الجهاز لترتيب عمليات الكتابة قسريًا قبل الأمر وبعده؛ أو بدلاً من ذلك وجود أمر حائل (barrier) يسهل الترتيب ولكنه قد لا يدفع البيانات
3.: البيانات المرسلة للكتابة في إزاحة (offset) معينة للجهاز ستُكتب دون تغييرات أخرى على البيانات وعلى الإزاحة
4.: يمكن إعادة ترتيب عمليات الكتابة بواسطة الجهاز، ما لم تُسلسل صراحةً بواسطة أمر الدفع
5.: يمكن إعادة ترتيب عمليات القراءة والكتابة وتداخلها بحرية

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

عندما تسير الأمور على نحو خاطئ¶

عدم وجود ذرية أو وجود ذرية جزئية لقراءة/كتابة الكتل (1)

المشكلة: تُكتب محتويات كتلة جزئية (كتابة ممزقة)، على سبيل المثال بسبب خلل في الطاقة أو فشل إلكتروني آخر أثناء القراءة/الكتابة
الكشف: عدم تطابق المجموع التدقيقي عند القراءة
الإصلاح: استخدام نسخة أخرى أو إعادة البناء من كتل متعددة باستخدام مخطط ترميز معين

أمر الدفع لا يقوم بالدفع (2)

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

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

تتغير البيانات بصمت عند الكتابة (3)

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

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

تُكتب البيانات بصمت إلى إزاحة أخرى (3)

ستكون هذه مشكلة خطيرة أخرى حيث لا يملك نظام الملفات أي معلومات عن وقت حدوثها. لهذا السبب يجب اتخاذ التدابير مسبقًا. تُسمى هذه المشكلة أيضًا بشكل شائع الكتابة الشبحية (ghost write).

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

ما يلي يعتمد على المعلومات المتاحة علنًا، وتعليقات المستخدمين، والمناقشات المجتمعية أو تحليلات تقارير العلات. إنها ليست كاملة ويُشجع على إجراء المزيد من البحث عند الشك.

الذاكرة الرئيسة¶

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

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

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

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

لن يؤثر نظام الملفات الموصول للقراءة فقط على الجهاز الكتلي الأساس بنسبة تقترب من 100% (مع استثناءات مستبعدة للغاية). الاستثناء هو سجل الشجرة (tree-log) الذي يتطلب إعادة تشغيله أثناء الوصل (وقبل أن يحدث الوصل للقراءة فقط)، وهناك حاجة إلى ذاكرة عمل من أجل ذلك والتي يمكن أن تتأثر بانقلابات البتات. هناك حالة نظرية حيث يغير انقلاب البت حالة نظام الملفات من القراءة فقط إلى القراءة والكتابة.

قراءات إضافية:

https://en.wikipedia.org/wiki/Row_hammer
كسر سرعة الذاكرة، وXMP، والمخاطر المحتملة

ما العمل:

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

الوصول المباشر إلى الذاكرة (DMA)¶

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

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

ما العمل:

استخدم نواة حديثة (الإصدارات الأخيرة أو الإصدارات المدعومة طويلاً والمصانة)
بما أن هذا قد ينتج عن برامج تشغيل معيبة، أبقِ الأنظمة محدثة

الأقراص الدوارة (HDD)¶

تفشل أقراص HDD الدوارة عادةً على مستوى القطاعات الفردية أو العناقيد الصغيرة. تُلتقط إخفاقات القراءة في المستويات الأدنى من نظام ملفات وتُرجع للمستخدم كخطأ EIO - Input/output error. قد تؤدي قراءة الكتل بشكل متكرر إلى استعادة البيانات في النهاية، ولكن يُفضل القيام بذلك عبر أدوات متخصصة، ويأخذ نظام ملفات بنتيجة الطبقات الأدنى. قد تؤدي إعادة كتابة القطاعات إلى تحفيز إعادة تعيين داخلي ولكن هذا يؤدي حتمًا إلى فقدان البيانات.

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

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

ما العمل:

•: افحص smartctl بحثًا عن المشاكل المحتملة

محركات الحالة الصلبة (SSD)¶

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

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

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

هناك تقنيات ومصنعون متعددون لذا يصعب وصفهم جميعًا ولكن هناك بعض الأنواع التي تظهر سلوكًا متشابهًا:

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

لا يمكن تحديد العمر المتوقع لمحرك SSD بشكل موثوق بسبب نقص المعلومات حول كيفية عمله أو بسبب نقص الإحصائيات الموثوقة التي يوفرها الجهاز.

تميل كتابة البيانات الوصفية إلى أن تكون المكون الأكبر لعمليات الكتابة مدى الحياة على محرك SSD، لذا فإن هناك قيمة في تقليلها. اعتمادًا على فئة الجهاز (راقٍ/منخفض) فإن الميزات مثل تشكيلات مجموعات الكتل DUP قد تؤثر على الموثوقية بكلا الاتجاهين:

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

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

قراءات إضافية:

ما العمل:

شغّل smartctl أو الفحوصات الذاتية للبحث عن المشاكل المحتملة
أبقِ البرمجيات المضمنة محدثة

الذاكرة غير المتطايرة السريعة (NVMe)¶

ذاكرة NVMe هي نوع من الذاكرة المستديمة التي تتصل عادةً عبر ممر النظام (PCIe) أو واجهة مشابهة، وتكون سرعتها أسرع بترتيب فرعي كامل من محركات SSD. وهي أيضًا نوع تخزين غير دوار، ولا تُوصل عادةً بكابل. كما أنها ليست جهازًا من نوع SCSI بل هي مواصفة كاملة لواجهة الأجهزة المنطقية.

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

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

البرمجيات المضمنة للمحرك¶

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

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

ما العمل:

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

بطاقات ذاكرة وميضية SD¶

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

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

العتاد كمصدر رئيس لتلف نظام ملفات¶

إذا كنت تستخدم عتادًا غير موثوق ولا تعلم ذلك، فلا تلم نظام ملفات عندما يخبرك بذلك.

انظر أيضًا¶

acl(5), btrfs(8), chattr(1), fstrim(8), ioctl(2), btrfs-ioctl(2), mkfs.btrfs(8), mount(8), swapon(8)

ترجمة¶

تُرجمت هذه الصفحة من الدليل بواسطة زايد السعيدي <zayed.alsaidi@gmail.com>

هذه الترجمة هي وثيقة مجانية؛ راجع رخصة جنو العامة الإصدار 3 أو ما بعده للاطلاع على شروط حقوق النشر. لا توجد أي ضمانات.

إذا وجدت أي أخطاء في ترجمة صفحة الدليل هذه، يرجى إرسال بريد إلكتروني إلى قائمة بريد المترجمين: kde-l10n-ar@kde.org.

Source file:	btrfs.5.ar.gz (from man-pages-ar 4.31.0-1.1)
Source last updated:	2026-06-29T09:41:50Z
Converted to HTML:	2026-07-03T00:56:00Z