الخلاصة

  • نسخة 26 سبتمبر وثيقة عمل نشطة لدى مجموعة NFSv4 وحالتها في سجل IETF هي I-D Exists؛ ليست RFC معتمدة.
  • الإضافة الخاصة بـ pNFS تفصل بين إزالة قدم القيم المخزنة عند العميل وبين وصول الحجم المعدل إلى خادم البيانات الوصفية.

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

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

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

لا تعني هذه الحالة أن كل ترتيبات pNFS تتأخر بالطريقة نفسها. النص يربطها بتخطيط يعتمد وصول التعديل عبر LAYOUTCOMMIT. كذلك لا يعد بصورة لحظية شاملة لكل الأجهزة أو بلقطة ذرية للدليل. كلمة «حديث» تحتاج إلى مرجع: حديث قياساً بآخر تعداد محفوظ لدى العميل، أم حديث قياساً بكل كتابة تمت على مسار البيانات؟ السمة تعالج المعنى الأول وحده.

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

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

المصادر