الخلاصة

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

ثلاث جهات، وثلاث صور مختلفة للملف

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

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

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

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

ما الذي يصل إلى الخادم فعلًا؟

تعرض إجراءات NFSv2 عمليات مثل LOOKUP وREAD وWRITE وCREATE وREMOVE وRENAME. يستقبل REMOVE مرجع دليل واسمًا كي يزيل المدخل المقابل. لا توجد في واجهة الإصدار الثاني عمليتا OPEN وCLOSE عن بعد تنشئان لدى الخادم سجلًا بفتح العميل للملف ثم انتهاء آخر مرجع إليه.

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

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

إعادة التسمية تؤجل القرار النهائي

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

ينفصل بذلك وقت اختفاء الاسم عن وقت إزالة المدخل البعيد. وقد تنفذ عبارة المستخدم «احذف الملف» عدة خطوات على جهتين وفي أوقات مختلفة. الاسم المرئي يختفي الآن؛ أما التنظيف فينتظر معلومة لا يملكها الخادم.

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

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

«عديم الحالة» لا يعني «بلا بيانات»

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

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

اختار NFSv3 لاحقًا واجهة إجراءات لا تتضمن OPEN وCLOSE عن بعد. أما RFC 7530 الخاصة بـNFSv4 فتتضمن عمليتي الفتح والإغلاق ومعرّفات حالة stateid. لا يثبت ذلك أن كل المواقع انتقلت أو أن جميع التطبيقات اكتسبت معنى متطابقًا؛ إنه يبين أن إدخال حالة الفتح في البروتوكول خيار تصميم له كلفة تنسيق.

حين تكون المعلومة عند طرف واحد والقرار عند آخر

يدير الخادم الدليل المصدّر وينفذ REMOVE. ويعرف نظام العميل العمليات التي تحتفظ بمرجع مفتوح. من دون إرسال تلك المعلومة، لا يستطيع الخادم وحده اختيار لحظة آمنة للإزالة النهائية. حيلة إعادة التسمية تربط بين ما يعرفه الطرفان، لكنها تجعل سجل التنظيف والتعافي مسؤولية يجب على العميل توفيرها.

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

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

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

المصادر وحدود الدليل

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