كيفية إعادة تسمية ملف في Posix بشكل قاطع؟

Question

ما هي الطريقة الصحيحة لإعادة تسمية ملف في نظام ملفات posix؟ تتساءل على وجه التحديد عن FSYNCs على الدلائل. (إذا كان هذا يعتمد على OS/FS ، فأنا أسأل عن Linux و Ext3/Ext4).

ملحوظة: هناك أسئلة أخرى حول StackOverflow حول إعادة تسمية دائمة ، لكن AFAICT لا يعالجون FSYNC -ING DERDITIONS (وهو ما يهمني - أنا لا أقوم حتى بتعديل بيانات الملف).

لدي حاليا (في بيثون):

dstdirfd = open(dstdirpath, O_DIRECTORY|O_RDONLY)
rename(srcdirpath + '/' + filename, dstdirpath + '/' + filename)
fsync(dstdirfd)

أسئلة محددة:

• هل هذا أيضًا ضمنيًا FSYNC دليل المصدر؟ أو قد ينتهي بي الأمر بالملف الذي يظهر في كلا الدلتين بعد دورة الطاقة (وهذا يعني أنه يجب علي التحقق من عدد الارتباطات الصعبة وأداء الاسترداد يدويًا) ، أي أنه من المستحيل ضمان عملية تحرك ذرية بشكل قاطع؟
• إذا كنت fsync دليل المصدر بدلاً من دليل الوجهة ، هل سيؤدي ذلك أيضًا ضمنيًا إلى دليل الوجهة؟
• هل هناك أي أدوات اختبار/تصحيح/تعليمية مفيدة ذات صلة (حقن الأخطاء ، وأدوات التأمل ، ونظم الملفات الوهمية ، وما إلى ذلك)؟

شكرا مقدما.

Answer 1

يحدد Posix أن يجب أن تكون وظيفة إعادة تسمية ذرية.

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

لكن هذا لا يحل مشكلة التأكد من أن عملية إعادة التسمية () متينة. يجيب Posix على هذا السؤال:

إذا تم تعريف _posix_synchronized_io ، فيجب أن تجبر وظيفة FSYNC () جميع عمليات الإدخال/الإخراج المرتبطة بالملف المشار إليها بواسطة FILDES واصف الملف إلى حالة إكمال I/O المتزامنة. يجب إكمال جميع عمليات الإدخال/الإخراج على النحو المحدد لاستكمال سلامة ملف I/O المتزامن.

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

أخيرًا ، على عكس المطالبة الواردة في منشور المدونة المذكور في إجابة أخرى ، يفسر الأساس المنطقي لهذا ما يلي:

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

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

(تم تحديثه بمعلومات إضافية:

Answer 2

لسوء الحظ ، إجابة ديف خاطئة.

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

يجب أن يكون السؤال الحقيقي:

كيف تقوم بإعادة تسمية متينة على الأنظمة التي تدعم ذلك من خلال واجهة برمجة تطبيقات POSIX؟

تحتاج إلى القيام بـ FSYNC () على كلاهما ، المصدر و دليل الوجهة ، نظرًا لأن الحد الأدنى الذي من المفترض أن يفعله Fsync () هو كيف يجب أن يبدو دليل المصدر أو الوجهة.

هل fsync (destdirfd) أيضا ضمني fsync الدليل المصدر؟

• Posix بشكل عام: لا ، لا شيء يعني ذلك
• Ext3/4: لست متأكدًا مما إذا كان كلتا التغييرات في المصدر والوجهة تنتهي في نفس المعاملة في المجلة. إذا فعلوا ذلك ، فإنهم يحصلون على كلاهما معًا.

أو قد ينتهي بي الأمر بالملف الذي يظهر في كلا الدلتين بعد دورة الطاقة ("Crash") ، أي أنه من المستحيل ضمان عملية تحرك ذرية بشكل كبير؟

• POSIX بشكل عام: لا توجد ضمانات ، لكن من المفترض أن تكون FSYNC () كلا الدليلين ، والتي قد لا تكون ذرية
• Ext3/4: مقدار FSYNC () الذي تحتاجه إلى الحد الأدنى يعتمد على خيارات التثبيت. على سبيل المثال ، إذا تم تثبيته بـ "dirsync" ، فلن تحتاج إلى أي من هذين fsync () s. على الأكثر ، تحتاج إلى كل من FSYNC () ، لكنني متأكد تقريبًا من أن أحدهما كافٍ (مدين ذريًا في ذلك الوقت).

إذا كنت fsync دليل المصدر بدلاً من دليل الوجهة ، فهل هذا أيضًا ضمنيًا دليل الوجهة؟

• Posix: لا
• Ext3/4: أعتقد حقًا أن كلاهما ينتهي به المطاف في نفس المعاملة ، لذلك لا يهم أي منهما fsync ()
• kernels الأقدم ext3: (إذا لم تكن في نفس المعاملة) ، فإن بعض التنفيذ غير الأمثل لم يكن متزامنًا كثيرًا على FSYNC () ، أراهن أنه ارتكب كل معاملة جاءت من قبل. ونعم ، من شأن التنفيذ العادي أولاً ربطه بالوجهة ثم إزالته من المصدر. لذلك فإن FSYNC (SRCDIRFD) من شأنه أن يؤدي إلى FSYNC () من الوجهة أيضًا.
• Ext4/أحدث ext3: إذا لم تكن في نفس المعاملة ، فقد تتمكن من مزامنةها بشكل مستقل بشكل كامل (وكذلك الحالتين)

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

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

وللتعلم: اكتشف ما إذا كان كلتا التغييرات مرتبطة بطريقة ما في المجلة! : p

Answer 3

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

سأبدأ من خلال قراءة صفحة MAN RENAEM (2) على النظام الأساسي الذي تستخدمه.

Answer 4

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

على أي حال ، يبدو أن هذه المقالة تتناول أسئلتك بخصوص FSYNC:http://blogs.gnome.org/alexl/2009/03/16/ext4-vs-fsync-my-take/