الخلاصة

  • تتيح عملية LAYOUT_WCC للعميل أن يرسل إلى خادم البيانات الوصفية سمات ما بعد العملية التي تلقاها بالفعل من خادم بيانات يعمل عبر NFSv3.
  • يستطيع الخادم الاستفادة من الإفادة لتفادي GETATTR، أو تجاهلها، أو إجراء فحص مباشر؛ ولا تتضمن النتيجة بياناً منفصلاً بالسمات المقبولة.
  • صحة السمات المرصودة لا تثبت استقرار البايتات في التخزين، ولا تطابق كل النسخ المتطابقة، ولا النتيجة التي وصلت إلى التطبيق.

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

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

فصل مسار البيانات صنع فجوة في الرؤية

يقسّم pNFS العمل بين مستوى البيانات الوصفية ومستوى البيانات. يدير خادم البيانات الوصفية مساحة الأسماء، ويمنح التخطيطات ويستردها، ويمكنه تنفيذ الإدخال والإخراج بنفسه. لكن التخطيط قد يوجّه العميل إلى خوادم بيانات تحمل المحتوى، ويسمح flexible file layout بأن تتكلم تلك الخوادم إصدارات قائمة من NFS، ومنها NFSv3.

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

يوفر GETATTR طريقاً واضحاً لاستعادة الرؤية. يمكن لخادم البيانات الوصفية أن يجلب الحجم والمساحة والأزمنة الحالية من خادم البيانات. غير أن كل فحص يضيف طلباً إلى مستوى التخزين، وقد يتحول سيل استعلامات البيانات الوصفية إلى عبء ملحوظ. كما أن WRITE ثم GETATTR في NFSv3 يحتاجان رحلتين، في حين تستطيع عملية مركبة في NFSv4 جمع العمل والسمات.

يسجل RFC 9766 العملية رقم 77 في NFSv4.2 باسم LAYOUT_WCC. وقد تحمل إجابات READ وWRITE وCOMMIT في NFSv3 بيانات Weak Cache Consistency. يحوّل العميل هذه القيم إلى سمات NFSv4.2 ويرفعها إلى خادم البيانات الوصفية بدلاً من التخلص منها.

«ضعيف» حد للدلالة لا عيب في التسمية

يبني RFC 1813 بيانات WCC من سمات مختارة قبل العملية وسمات بعدها. تساعد المقارنة العميل في استنتاج احتمال حدوث تغيير آخر وتحديد ما إذا كان ينبغي إبطال محتوى مخبأ. وهي أوسع دلالة من لقطة أخيرة منفردة.

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

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

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

ثماني سمات لا تنتج حكماً واحداً

تغطي الحمولة الخاصة بـ flexible file layout ثمانية حقول: size وspace_used وmode وowner وowner_group وtime_access وtime_modify وtime_metadata. وتتحول قيم uid وgid الرقمية إلى قيم نصية للمالك والمجموعة في NFSv4.

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

يذكر RFC مواقف يمكن أن توفر فيها الإفادة عملاً: قبل أن يطلب العميل من خادم البيانات الوصفية الحجم أو المساحة أو change attribute أو الأزمنة؛ وعند إبلاغ NFS4ERR_ACCESS كي يقارن الخادم uid/gid المتوقعين بما شوهد؛ وعند تحديث أزمنة الوصول والتعديل تحت تفويض مناسب.

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

هوية ملف البيانات ليست رقم موضعه

تربط العملية التقرير بالتخطيط باستخدام filehandle الحالي وlowa_stateid، ويحدد lowa_type طريقة تفسير الحمولة المعتمة. وفي flexible file layout يمكن للحمولة وصف النسخ المتطابقة وخوادم البيانات الموجودة تحتها.

قد تبدو المصفوفة وكأنها تمنح كل كائن هوية ترتيبية. لكن عميلاً لديه ثلاث نسخ يستطيع إرسالها كلها مع mask فارغ للنسخة التي لم تتغير، أو إرسال النسختين المتغيرتين فقط. عندئذ لا يعود «العنصر الثاني» الكائن نفسه. يلزم التعرف إلى ملف البيانات بمزيج device ID وstateid وfilehandle. ولا يكفي الجهاز وحده، إذ يستطيع التخطيط وضع أكثر من ملف بيانات على الجهاز ذاته.

المبدأ أوسع من بنية الحزمة: التجاور ليس هوية. الدليل الذي سيبقى صالحاً بعد الحذف وإعادة الترتيب يحتاج مفاتيح تسمي الكائن ذاته.

وتزيد الأخطاء ضرورة هذا التفصيل. عند وقوع خطأ مسموح، يستطيع خادم البيانات الوصفية تجاهل العملية بكاملها أو، إذا سمحت حمولة التخطيط، تطبيق جزء منها. سجل «نجح/فشل» لا يكشف أي ملف أو أي سمات دخلت القرار. يلزم سجل يحتفظ بالهوية والـmask والقيم وقرار التطبيق.

الإفادة ليست التزاماً بالتخزين

قد يوحي الحجم أو زمن التعديل بأن البيانات أصبحت آمنة. لكنهما ليسا إيصال تخزين مستقر. إذا لم تعد الكتابة FILE_SYNC، يفرض flexible file layout على العميل جعل الكتابات غير المستقرة مستقرة بواسطة COMMIT قبل LAYOUTCOMMIT. لا تختصر LAYOUT_WCC هذه السلسلة.

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

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

الاختيارية تحافظ على مسار الرجوع

العملية اختيارية في NFSv4.2 وفي flexible file layout. لذلك يستطيع عميل أو خادم لم ينفذ العملية 77 أن يظل متوافقاً عبر المسارات السابقة، ومنها الاستعلام المباشر. قد يدفع كلفة عمل إضافي، لكن غياب التحسين لا يعني بطلان التنفيذ.

يضع RFC 8178 قواعد تمديد NFSv4، ويقدم RFC 7862 وRFC 7863 أساس البروتوكول ووصف XDR في NFSv4.2. تثبت هذه الوثائق الصيغة والحالة المعيارية. أما إثبات التفاوض على الميزة واستخدامها فلا يأتي إلا من نقاط طرفية تعمل فعلاً.

يرث الامتداد نموذج الأمان من flexible file layout. قد يستخدم loose coupling قيماً مصطنعة لـ uid/gid لعزل العملاء المتعاونين، لكنه لا يحمي بالضرورة من عميل خبيث ولا يستطيع دائماً عزل عميل واحد. ويتوقف tight coupling على بروتوكول التحكم الخاص به. كما ينبغي حماية اتصالات الخلفية من الرصد والتلاعب. توثيق هوية العميل يثبت من أرسل الإفادة عبر القناة، ولا يثبت أن كل قيمة هي أحدث ما على خادم البيانات.

المصادر

  1. RFC 9766: Extensions for Weak Cache Consistency in NFSv4.2's Flexible File Layout
  2. RFC 8435: Parallel NFS Flexible File Layout
  3. RFC 8434: Requirements for pNFS Layout Types
  4. RFC 1813: NFS Version 3 Protocol
  5. RFC 8881: NFS Version 4 Minor Version 1 Protocol
  6. RFC 7862: NFS Version 4 Minor Version 2 Protocol
  7. RFC 7863: NFSv4.2 XDR Description
  8. RFC 8178: Rules for NFSv4 Extensions and Minor Versions
  9. RFC 9754: Extensions for Opening and Delegating Files in NFSv4.2
  10. Running-Code Primacy
  11. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  12. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile