تحذير: تنطبق هذه المقالة على جميع أنظمة ملفات CoW على Linux التي تدعم إعادة الارتباط عند النسخ. في الوقت الحالي ، هذه هي: BTRFS و XFS و OCFS2.
يرجى الامتناع عن holivars حول أيهما أفضل: Btrfs أو XFS أو Reiser4 أو NILFS2 أو ZFS أو بعضها غير مذكور.قبل التاريخ
- 21 يوليو 2001 - تنشر Namesys إعلان Reiser4 . DARPA يرعى التطوير.
- 20 نوفمبر 2003 - تنشر Namesys بعض معايير Reiser4 .
- 24 أغسطس 2004 - Namesys تصدر نشرة عامة عن Reiser4 .
- 14 سبتمبر 2004 - إعلان ZFS.
- 16 نوفمبر 2005 - تم تضمين ZFS في OpenSolaris build 27.
- سبتمبر 2006 - اعتقال هانز ريزر بتهمة قتل زوجة نينا ريزر. بداية نهاية Namesys
- 12 يونيو 2007 - إعلان Btrfs من كريس ماسون (موظف سابق في Namesys).
- 22 سبتمبر 2011 - ظهرت تذكرة مع طلب لتنفيذ reflink في ZFSonLinux.
- 2012 - تم التعرف على Btrfs باعتبارها Oracle Linux و SUSE Linux Enterprise مستقرة
- 21 كانون الثاني (يناير) 2013 - تمت إزالة تسمية التجربة باستخدام Btrfs في التعليمات البرمجية المصدر لنظام Linux kernel.
- مايو 2019 - تمت إزالة Btrfs من RHEL 8 (أسباب سياسية خفية يشتبه بأنها Btrfs التي روجت لها Oracle)
نسخ التوقعات في أنظمة ملفات CoW
عندما تم الإعلان عن Reiser4 في عام 2001 ، كنت مصدر إلهام وشغفًا بنسخ الكتابة. مجرد التفكير ، يمكننا بسهولة وبسهولة الحصول على أكبر عدد ممكن من نسخ المشاريع المختلفة كما تشاء ، وسيعمل القرص فعليًا على تخزين الاختلافات بينهما!
بالإضافة إلى ذلك ، يجب أن تنمو سرعة النسخ بشكل غير لائق. نظرًا لحقيقة أنه عند النسخ ، سيتم إنشاء رابط رابط للملف القديم فقط. عند الكتابة إلى هذا الملف الجديد ، سيتم تخصيص قطاعات البيانات التي تم تغييرها تلقائيًا. نتيجة لذلك ، سيكون لدينا نفس القطاعات للأجزاء الشائعة من الملفات ، وسيتم تسجيل الأجزاء المختلفة في القطاعات المختلفة.
بعد ذلك ، بدا الأمر وكأنه الدواء الشافي لإنشاء حسابات للاستضافة المشتركة ، وهو الآن أفضل حل للأجهزة والحاويات الافتراضية خفيفة الوزن. بعد كل شيء ، لم نتمكن من إضاعة مساحة على ملفات مماثلة ، في نفس الوقت السماح للمستخدمين بتغييرها بسهولة.
ومع ذلك ، ذهب هانز ريسر إلى السطح وقتل زوجته ، ولم يتم تضمين بنات أفكاره (على الأرجح لأسباب سياسية) في القلب. ربما ، بعد كل شيء ، تعتمد القصة على شخص معين؟
تم نشر ZFS بموجب ترخيص غير متوافق مع Linux ، وبالتالي لم يتم تضمينه في النواة. لذلك ، تم إبطاء إدخال ZFS في Linux لفترة طويلة.
بعد ذلك بدأت في الانتظار ل Btrfs. وبعد 6 سنوات فقط من الإعلان ، تم التعرف عليه من قبل مطوري Linux kernel على أنه مستقر.
بعد ذلك ، أخذت بعض الوقت في استخدام أنظمة Cow ، لأن نموذج النسخ على الكتابة نفسه يعني زيادة التجزئة ، لأن تغييرات البيانات تتم كتابتها إلى مكان جديد في كل مرة.
بالنسبة للقرص الصلب ، يقتل التفتت الأداء ، لأن عملية تغيير موضع رأس القراءة عملية طويلة جدًا.
لذلك ، قمت شخصياً بتأجيل تنفيذ btrfs على أجهزتي حتى تحولوا إلى SSD.
ألاحظ أن محركات أقراص الحالة الصلبة أيضًا لا تحب التجزئة ، فالكل يعرف أن SSD ، يمكن أن تكون القراءة / القراءة الخطية أسرع بعشرات المرات من الوصول العشوائي.
لكن أداء SSD المجزأة ليس دراماتيكيًا مثل أداء محرك الأقراص الصلبة.
لذا ، ماذا عن سرعة النسخ مع CoW؟
وأخيرا ، لقد حان الوقت. عندما أصبحت SSDs موثوقة بدرجة كافية ، بدأت في استخدام أنظمة ملفات CoW مع القوة والرئيسية. بشكل أكثر تحديدا ، Btrfs و Nilfs2.
اتقان إمكانيات اللقطات المثيرة ، لقد نسيت بعض الوقت توقعاتي منذ عام 2000 حول نسخ الملفات بسرعة فائقة.
بعد بعض الوقت ، قررت إجراء الاختبارات. وخيبة أمل كبيرة ، لم أر أي زيادة في السرعة من CoW عند النسخ. هذه هي النتيجة على SATA SSD:
time cp -a /usr /usr1 real 0m15,572s user 0m0,240s sys 0m4,739s
اتضح أنه لاستخدام CoW تحتاج إلى تحديد مفتاح خاص.
time cp -a --reflink=auto /usr /usr2 real 0m3,166s user 0m0,178s sys 0m2,891s
فقط في هذه الحالة نرى ميزة 5 أضعاف. بالمناسبة ، ينمو حجم الميزة إلى أجل غير مسمى مع زيادة طول الملف. المجلد
/usr الذي قمت بنسخه هو في الغالب ملفات صغيرة.
لقد فوجئت بشكل لا يصدق لماذا لا يتم استخدام الميزة الرئيسية لنظام ملفات CoW بشكل افتراضي. في الواقع ، لهذا تم إنشاؤها!
في هذه الحالة ، اختبرت النسخ على قسم Btrfs. لكنك ستحصل على نتيجة مماثلة مع أي نظام ملفات CoW آخر يدعم reflink.
ما هي المشكلة ، بيلي؟
المشكلة في حزب المحافظين. بشكل افتراضي ، لا يستخدم CoW عند النسخ. على الرغم من أنه يمكن.
يمكنك القول - أنا لا أستخدم cp. ومع ذلك ، تحت غطاء نظام التشغيل Linux ، يتم استخدامه في كل مكان تقريبًا. العديد من البرامج ، عندما يحتاجون إلى نسخ شيء ما ، استخدم cp ، وليس "الدراجات" الخاصة بهم.
لماذا اتخذ المطورون الأساسيون قرارًا غامضًا ، والذي تجاوز نصف مزايا أنظمة ملفات CoW؟
اتضح أن هذا هو ما قرره براديج برادي ، المسؤول عن تطوير غنو الأساسية.
هنا هو منطقه :
- بشكل افتراضي ، لا يستخدم cp CoW ، حيث قد يستخدم شخص ما النسخ من أجل زيادة احتمال حفظ الملف على القرص بعد تدمير نظام الملفات.
- فيما يتعلق بالأداء ، إذا كان هناك نوع من العملية الحساسة للتأخير ، فقد ترغب في إنشاء السجل الرئيسي أثناء النسخ ، لذلك إذا حدث ذلك لاحقًا ، فقد يكون هناك تأخير عند إعادة وضع رؤوس القرص الصلب. يرجى ملاحظة أنه بدءًا من الإصدار 8.24 coreutils ، يستخدم mv خيار reflink افتراضيًا.
نص الإجابة Pádraig Brady باللغة الإنجليزيةهذا ليس هو الوضع الافتراضي لأنه لأسباب قوية قد يرغب المرء في عمل نسخة للحماية من تلف البيانات. أيضًا لأسباب تتعلق بالأداء ، قد ترغب في حدوث عمليات الكتابة في وقت النسخ بدلاً من عملية حساسة زمن الوصول تعمل على ملف CoW وتتأخر بسبب عمليات الكتابة إلى جزء آخر من قرص ميكانيكي. لاحظ أنه من coreutils v8.24 mv سيعيد الارتباط بشكل افتراضي ، لأنه لا يحتوي على القيود المذكورة أعلاه.
من حيث سرعة mv ، لا يوجد عمليا أي فائدة من CoW عند نقل الملفات. ضمن نظام ملفات واحد ، يعمل mv دائمًا بشكل سريع جدًا.
مرة أخرى ، السؤال الذي يطرح نفسه هو تأثير الشخصية على التاريخ. من خلال وضع عدة أحرف في شفرة مصدر البرنامج بشكل مختلف ، يمكنك إبطاء النسخ لعشرات / مئات الملايين من المستخدمين (هنا تحتاج إلى مراعاة أن معظم الناس يستخدمون الآن الخدمات السحابية بشكل أو بآخر ، حتى لو لم يكن لديهم جهاز كمبيوتر) ، مما يقلل من كفاءة استخدام محركات الأقراص وزيادة مبيعاتها في جميع أنحاء العالم.
Pádraig تحليل الحجة
الحجة الأولى منطقية. يمكن للمستخدمين عديمي الخبرة عمليا النسخ الاحتياطي للملفات القيمة على نفس نظام الملفات.
الحجة الثانية. إذا قرأت المزيد من التعليقات حول التخلفات في Pádraig ، فقد تبين أنه كان يفكر في مواقف قاعدة البيانات حيث عند الكتابة إلى ملف موجود ، قد يكون هناك تأخير بسبب نظام الملفات الذي يبحث عن مساحة خالية. ولكن في حالة نظام ملفات CoW ، سيتم دائمًا البحث عن قطاعات جديدة للتسجيل نظرًا لطبيعة CoW ، كما لاحظ Jan Kanis. لذلك ، في رأيي ، فإن الحجة الثانية لا يمكن الدفاع عنها.
ومع ذلك ، في أنظمة CoW ، من الممكن بالفعل الحصول على تأخير أو حتى خطأ "نفاد مساحة" عند الكتابة إلى ملف قاعدة البيانات. لتجنب ذلك ، تحتاج في البداية إلى إنشاء دليل فارغ مع تعطيل CoW لقاعدة البيانات.
تعطيل CoW على الدليل / الملف مثل هذا:
chattr +C /dir/file chattr +C /dir/dir
هناك أيضا خيار لتحميل nodatacow. سيتم تطبيقه على جميع الملفات التي تم إنشاؤها حديثا.
ولكن ماذا لو أردنا استخدام CoW عند النسخ افتراضيًا؟
- الطريقة الجذرية هي تصحيح البطينات. ربما قم بإنشاء الحزمة الخاصة بك في مستودعك الخاص.
ملف تصحيح cp.c :
-x->reflink_mode = REFLINK_NEVER; +x->reflink_mode = REFLINK_AUTO;
- الحل الأقل جذرية هو كتابة اسم مستعار cp ل shell الخاص بك. للباش ، على سبيل المثال:
في المجلد /etc/profile.d ، قم بإنشاء cp_reflink.sh cp_reflink.sh مع المحتويات:
سيعمل هذا الحل في جميع الحالات تقريبًا عند الوصول إلى cp من shell بالاسم. ولكن إذا تم استخدام / bin / cp في البرامج النصية ، فلن يعمل الاسم المستعار وسيحدث النسخ كالمعتاد.
مديري الملفات والارتباط
الحالة اعتبارًا من 31 أكتوبر 2019:
- قائد منتصف الليل - يدعم.
- Krusader - لا يدعم.
- دولفين - لا يدعم.
- نوتيلوس - لا يدعم.
- نيمو - يدعم.
لغات البرمجة ومكالمات النظام والارتباط
لا تملك معظم لغات البرمجة دعم reflink.
في C ، لا يزال العديد من المبرمجين
ينسخون باستخدام الحلقات والمخازن المؤقتة .
لا يستخدم استدعاء نظام
sendfile reflink.
يستخدم
cp استدعاء نظام
ioctl مع علامة FICLONE.
أعتقد أنه إذا كنت بحاجة إلى نسخ شيء ما في الكود ، فمن المستحسن أن تفعل ذلك كما يفعل
cp أو فقط اتصل بـ
cp --reflink=auto .
النتائج
مع ظهور عصر المحاكاة الافتراضية في كل مكان و SSD ، أصبح من المهم للغاية استخدام أنظمة ملفات CoW. أنها مريحة لإنشاء لقطات ، نسخ سريع. في الواقع ، عند استخدام CoW عند النسخ ، نقوم
تلقائيًا بإلغاء
البيانات المكررة .
حاليًا ، هناك 3 أنظمة ملفات فقط تدعم هذا النوع من النسخ: BTRFS و XFS و OCFS2.
آمل مخلصًا أن يتم دعم دعم reflink في ZFS و NILFS2 ، حيث إنهما يدعمان بالفعل CoW بواسطة الآليات الداخلية.
ومع ذلك ، في جميع توزيعات Linux ، يتم تعطيل CoW عند نسخ الملفات ، ونحن بحاجة إما إلى تحديد المفاتيح المقابلة بشكل صريح ، أو استخدام الحيل المختلفة مثل الأسماء المستعارة أو التصحيحات.
لقد مرت 18 عامًا منذ الإعلان عن Reiser4 ، ومع ذلك ، لم تدخل نسخ CoW خفيفة الوزن حتى الآن حياتنا في كل مكان.
PS عامل الميناء و CoW
هل تعرف أن Docker يدعم btrfs لتخزينه؟ يجب تمكين هذا الخيار. لم يتم تحديده بشكل افتراضي.
يعد نظام ملفات CoW من الناحية النظرية مكملاً مثاليًا للمحاكاة الافتراضية السهلة عندما تستخدم أجهزة افتراضية مختلفة نفس النواة.
في رأيي ، هو أكثر عضوية بكثير من OverlayFS و Aufs ، والتي هي عكازات تكنولوجية لمحاكاة CoW.
لاستخدام Btrfs في Docker ، تحتاج إلى:
- في تثبيت جديد (بدون صور وأجهزة افتراضية) لـ Docker ، قم بتركيب وحدة تخزين Btrfs منفصلة على
/var/lib/docker - إضافة خيارات إلى Docker Launch File Configuration
بالنسبة إلى Gentoo و Calculate Linux ، هذا هو
/etc/conf.d/docker DOCKER_OPTS="--storage-driver btrfs --data-root /var/lib/docker"
وإليك
التعليمات الكاملة لجميع التوزيعات.
إضافات من التعليقات
XFS و CoW
constb (
المصدر ): في XFS ، CoW غير معتمد دائمًا. تحتاج إلى إنشاء نظام ملفات باستخدام
mkfs.xfs -m reflink=1 .
بالفعل على FS تم إنشاؤه ، لا يمكنك "تمكين" دعم CoW. بالإضافة إلى ذلك ، على حبات تصل إلى 4.11 إدراج هذا الخيار يسبب تحذيرات حمراء في dmesg أن الميزة التجريبية.
MacOS و CoW
MMik (
المصدر ): في OS X ، هناك خيار مماثل للأمر
cp هو
-c .
يتضمن استخدام استدعاء النظام الذري
clonefile() ، الذي يقوم بإنشاء إدخال في نظام الملفات حول ملف جديد تشبه فيه الإشارات إلى كتل البيانات الأصل. يتم نسخ السمات والسمات الموسعة للملف وإدخالات قائمة التحكم في الوصول (ACL) ، باستثناء معلومات مالك الملف ومع إعادة تعيين وحدات البت setuid / setgid. إنه يعمل داخل نفس نظام الملفات ، ويتطلب الدعم من نظام الملفات (السمة ATTR_VOL_CAPABILITIES ، إشارة VOL_CAP_INT_CLONE).
معتمد منذ OS X 10.12 (Sierra) وفقط على نظام ملفات
APFS .
الشكر:
PPS توجيه الأخطاء لاحظت في شخصية. أنا زيادة الكرمة لهذا الغرض.
يمكنك تجربة أنظمة ملفات CoW عن طريق طلب جهاز افتراضي من
RUVDS باستخدام الكوبون أدناه.
