الخلاصة

  • فصل RFC 3010 اسم العميل المستقر عن نسخة تشغيله الحالية: verifier يتغير عند التهيئة وclientid تفاوضي وتأكيد موثّق، فلا يرث الاسم نفسه الأقفال القديمة تلقائياً.
  • عندما يفقد الخادم حالته، تمنح فترة سماح بطول الإيجار تقريباً الأولوية لطلبات reclaim وتؤخر الأقفال وعمليات الإدخال والإخراج الجديدة المتعارضة. الاستمرارية إجراء مؤقت وليست ملكية أبدية.

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

نُشر RFC 3010 في ديسمبر 2000 بوصفه أول مواصفة مكتملة لـNFSv4. عندما أُدخل القفل وحالة الفتح في البروتوكول، صار لزاماً تحديد كيف تُعرف السلطة المؤقتة بعد انهيار ذاكرة أحد الطرفين.

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

ربط SETCLIENTID المعرف وverifier بالـprincipal الموثق في نداء RPC. أعاد الخادم clientid قصيراً وverifier للتأكيد، وأغلق SETCLIENTID_CONFIRM الدورة. أصبح clientid مرجعاً محلياً فعالاً للحالة، لا هوية عالمية ولا سند ملكية ولا تفويضاً ينتقل بمجرد حيازته.

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

إذا عاد الـprincipal الصحيح بـverifier جديد، أمكن للخادم استنتاج نسخة تشغيل جديدة فقدت حالة القفل القديمة، ومن ثم تحرير أقفال clientid السابق. لكن المصادقة تحمي العملية: لا يجوز لغريب أن يدّعي إعادة تشغيل عميل آخر كي يمحو أقفاله. يحدد verifier تغير الحقبة، ويحدد principal من يملك إعلان ذلك.

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

الإيجار حماية مؤقتة لا حق دائم. بعد انقضائه يمكن للخادم استرداد الحالة ومنح التعارض. وقد يتلقى العميل العائد بعد انقسام طويل NFS4ERR_EXPIRED عند استعمال stateid قديم. عليه إبلاغ التطبيق بفقد الاستبعاد؛ ذاكرته المحلية لا تُلزم الخادم بلا نهاية.

عند إعادة تشغيل الخادم تنعكس الفجوة. يحتفظ العملاء بـclientid وstateid لا تعرفهما حقبة الخادم الجديدة. يكشف NFS4ERR_STALE_CLIENTID وNFS4ERR_STALE_STATEID الانقطاع. يجب إنشاء clientid جديد والدخول في التعافي، لا مواصلة العمل العادي بمراجع ميتة.

رتبت grace period هذا التعافي. خلال مدة تقارب lease، يرسل العملاء السابقون LOCK وOPEN بصيغة reclaim، بما فيها CLAIM_PREVIOUS. أبسط قاعدة آمنة أن يرد الخادم بـNFS4ERR_GRACE على locks وopens وreads وwrites الجديدة. الخادم متصل، لكن سلطة إنشاء تعارض جديد معلقة مؤقتاً.

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

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

بعد نهاية النافذة لا يتقدم reclaim المتأخر تلقائياً. لا ينجح إلا إذا ضمن الخادم عدم منح قفل أو إدخال وإخراج متعارض منذ الإقلاع. للحقائق الجديدة المكتملة وزن أيضاً. جعل الموعد تكلفة عدم اليقين محدودة.

عرض RFC 2624 ضغوط التصميم، ثم حل RFC 3530 محل RFC 3010، وأصبح RFC 7530 صياغة لاحقة لـNFSv4.0. المقال تاريخ للآلية لا إرشاد إعداد حالي.

في NFSv4.1 أضاف RFC 5661 EXCHANGE_ID والجلسات وتعافياً أدق. ويبيّن بديله RFC 8881 ثمن التساهل: كلما أراد الخادم قبول reclaims أكثر بعد الأعطال الصعبة، وجب أن يحفظ دليلاً أكثر عن العملاء والحالة في تخزين مستقر.

من منظور Running-Code Primacy عند Lu Heng، الحق الفعلي هو ما يستطيع الخادم الجديد التحقق منه محلياً: principal ونسخة التشغيل وlease وصيغة reclaim والنافذة وغياب تعارض لاحق. تمنع القاعدة المشتركة الدنيا الوافد الجديد من الفوز لأن العطل جعله أول الواصلين.

تقع Stability Fallacy حين يبدو الاسم أو نظام الملفات ثابتاً فيُعامل كسلطة مستمرة. كشف RFC 3010 الفقد برسائل stale، وأوقف التعارضات، وطلب إعادة بناء الإيصالات. لم يبق القفل لأن العميل تذكره؛ حصل على فرصة لأن البروتوكول تذكر ترتيب التعامل مع النسيان.

Sources