الخلاصة

  • تعرّف مسودة NFSv4.2 التي وافق عليها IESG قيمة منطقية لكل ملف تطلب من العملاء الداعمين الحد من التخزين الطويل لبياناته، لكن تطبيق السمة اختياري وإشارتها استشارية.
  • ظهور true لا يثبت أن عملية OPEN قائمة غيّرت نمطها، أو أن WRITE غير المستقرة أتمت COMMIT، أو أن بيانات pNFS الوصفية أصبحت مرئية، أو أن تطبيقاً آخر رأى البايتات.

سيستطيع الخادم أن يعبّر داخل البروتوكول عن حقيقة عملية: هذا الملف غير مناسب لذاكرة بيانات العميل المعتادة. في أحمال الحوسبة عالية الأداء والملفات التي يكتب فيها أكثر من عميل، يوفر ذلك لغة مشتركة بدلاً من تعديل كل تطبيق كي يستخدم سلوكاً محلياً شبيهاً بـ O_DIRECT.

لكن تسجيل الرغبة لا يمحو الذاكرة المؤقتة.

في 17 سبتمبر وافق IESG على Adding an Uncacheable File Data Attribute to NFSv4.2 وأحالها إلى طابور RFC Editor. تعرّف المراجعة 16 السمة fattr4_uncacheable_file_data بالرقم 87، وهي قيمة منطقية قابلة للقراءة والكتابة للملفات العادية والسمات المسماة. كلمة RECOMMENDED هنا فئة في NFS، ولا تعني أن على كل خادم تنفيذها.

الدعم خاص بكل نظام ملفات مُصدَّر، لا بعلامة الخادم كلها. قد يختلف تصديران من الجهاز نفسه. يفحص العميل supported_attrs أو يجرب. يفشل SETATTR غير المدعوم بـ NFS4ERR_ATTRNOTSUPP، أما GETATTR فيحذف الحقل فحسب. لذلك لا يمكن تحويل الغياب مباشرة إلى حكم تشغيلي.

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

للمتانة سلسلة مستقلة. لا تختار السمة قيمة stable_how4. بل تفرض المسودة أنه عند نجاح استدعاء الكتابة وعودته إلى التطبيق يجب أن تكون البيانات متينة على الخادم. يمكن استخدام FILE_SYNC4 أو DATA_SYNC4. وإذا استُخدم UNSTABLE4 فيجب أن يكتمل COMMIT قبل العودة؛ وإذا تغيّر write verifier وجب تكرار عمليات WRITE المتأثرة بينما ما زال مخزن التطبيق متاحاً.

الاحتفاظ المؤقت بالبايتات لإنهاء هذه العملية ليس التخزين الطويل الذي تستهدفه السمة. وفي الاتجاه المقابل، لا تعالج القيمة المنطقية غياب COMMIT. عبارة «غير قابل للتخزين المؤقت» سياسة للنسخة المحلية، وليست إيصالاً بأن البيانات أصبحت متينة.

للرؤية عند القراءة شروط أخرى. لا ينبغي لعميل يحتفظ ببيانات مقروءة أن يعيد استخدامها قبل التحقق من change attribute وحجم الملف. وقد توفر delegation رؤية متسقة بطريقة أخرى. في pNFS تأتي السمة من خادم البيانات الوصفية بينما تنتقل البايتات مباشرة إلى أجهزة التخزين. متانة البيانات هناك وظهورها عبر layout حدثان منفصلان. وإذا كان LAYOUTCOMMIT مطلوباً فإن تأخيره يترك عميلاً آخر يتحقق من بيانات وصفية أقدم.

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

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

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

لهذا يجب أن يربط السجل التشغيلي بين مراجعة المواصفة، ودعم التصدير، وسياسة الخادم، والقيمة التي رآها عميل محدد، وزمن OPEN، وإصدار التنفيذ، ونمط WRITE، وverifier وCOMMIT، وأي LAYOUTCOMMIT، وإعادة تحقق القراءة، والنتيجة التي رآها التطبيق. تبدأ سلسلة الإثبات بالقيمة المنطقية ولا تنتهي عندها.

المصادر