العميل الذي يعود أولاً لا ينهي مهلة الآخرين

الخلاصة

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

من يجيب عن سؤال انتهاء الاستعادة؟

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

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

هذا مثال يوضح سلوك البروتوكول، وليس تقريراً عن عطل وقع لدى جهة معينة. تشرح الأقسام 8.4 و9.11 و18.51 من RFC 8881 سبب الفصل في NFSv4.1 بين الأمرين. يمكن للعميل أن يعلن نجاح اكتمال استعادته، ثم يتلقى NFS4ERR_GRACE عند طلب قفل جديد. لا يعني ذلك بالضرورة أن إعلان الاكتمال السابق فشل.

فرصة للمطالبات التي لم تصل بعد

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

لاستعادة حالة فتح قائمة، يستخدم العميل OPEN مع CLAIM_PREVIOUS، ويحدد الملف الهدف بواسطة معرّف الملف الحالي في البروتوكول. ليست هذه عملية فتح اسم جديد انطلاقاً من مجلد. أما استعادة قفل نطاق من البايتات، فتستخدم LOCK مع تعيين معامل reclaim إلى القيمة الصحيحة.

لا تمنح صفة الاستعادة إعفاءً من شروط الوصول. تبقى الصلاحيات والتعارضات الفعلية معتبرة. لا يستطيع العميل الحصول على وصول محظور في الظروف العادية المناظرة بمجرد وصف طلبه بأنه قديم.

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

إعلان يغلق الباقي، لا يصف التقدم فقط

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

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

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

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

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

لا يمكن إحصاء الغائبين من قائمة الحاضرين

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

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

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

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

قفل متاح الآن، وحماية انقطعت سابقاً

تظهر المشكلة الأشد عندما يبقى اعتقاد العميل بملكيته القديمة بعد أن تكون الحماية نفسها قد انقطعت.

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

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

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

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

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

التطبيق لا يستعيد ماضيه بمجرد قفل جديد

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

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

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

تطرح الملاحظة 32 لـ Lu Heng عن مشكلة الوكالة سؤال العلاقة بين سلطة القرار وتحمل عواقبه. وتدعو الملاحظة 36 عن وصف الواقع لا الترويج لموقف إلى تفسير البنية بدلاً من اختراع صراع أخلاقي. تقدم الملاحظتان منظوراً تحريرياً هنا؛ أما الوقائع التقنية فمصدرها البروتوكول، وليست استنتاجاً عن دوافع مورّد بعينه.