الخلاصة

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

ما يعلنه الخادم ليس ما رآه العميل بعد

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

يحاول draft-ietf-nfsv4-uncacheable-files-13 سد فجوة لغوية في البروتوكول. فهو يضيف قيمة منطقية لكل ملف يستطيع الخادم من خلالها القول إن التخزين المؤقت المعتاد ليس مناسباً. غير أن لوحة تشغيل قد تحوّل القيمة الصحيحة بسهولة إلى عبارة «أُفرغت ذاكرة العميل». هذه العبارة لا يستطيع الخادم استنتاجها من السمة.

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

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

القدرة مرتبطة بنظام الملفات المصدّر

تحمل السمة الرقم 87، وهي قابلة للقراءة والكتابة، وتظهر في جدول سمات NFS ضمن فئة RECOMMENDED. الكلمة هنا تصنيف للسمة وليست أمراً مستقلاً يلزم كل تنفيذ لـ NFSv4.2 بدعمها. بل يمكن أن تختلف القدرة بين نظامي ملفات يصدّرهما الخادم نفسه.

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

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

الفصل بين القدرة والقيمة والسلطة يمنع نجاح اختبار على وحدة تخزين واحدة من التحول إلى تعميم غير صحيح عن منتج كامل.

نجاح الكتابة يعني ديمومة قبل العودة

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

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

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

السمة على الخادم لا تحمل هذه الأحداث. إنها توجه المسار، ولا تسجل اكتماله.

القراءة الجديدة تحتاج أساساً صالحاً لإعادة الاستخدام

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

ينسجم ذلك مع نموذج NFSv4.1 القائم. فلا تتحدد صلاحية الذاكرة بتقدير زمني محلي فقط، بل تتفاعل مع فتح الملف وحجوزات المشاركة والأقفال والتفويضات. وقد يمنح تفويضٌ العميل رؤية متسقة تجعل الاحتفاظ ببيانات قراءة مناسباً حتى عندما تكون السمة الجديدة صحيحة.

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

دفتر للخادم وإيصال للعميل

يجيب دفتر الخادم عن سؤال محدود: ما المعاملة التي أعلنها هذا الخادم لهذا الملف في هذه اللحظة؟ ويكفي أن يتضمن هوية الخادم ونظام الملفات المصدّر، ودعم السمة 87، وهوية الملف وقيمته، ومصدر السياسة، والجهة صاحبة القرار، ووقت الملاحظة.

أما إيصال العميل فيجيب: ماذا فعل هذا العميل بذلك الإعلان؟ يسجل التنفيذ وإصداره، والتركيب، ومقبض الملف، وحقبة الفتح، ووقت رؤية القيمة، وما إذا كان الملف مفتوحاً من قبل. وتضاف للقراءة قيم التغيير والحجم وسياق التفويض وإجراء الذاكرة، بينما تضاف للكتابة حالة الاستقرار وCOMMIT والمتحقق وإعادة الإرسال ووقت العودة إلى التطبيق.

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

كما يحدد هذا الفصل المسؤولية بدقة. قد تكون سياسة الخادم صحيحة بينما لا يفهم عميل قديم السمة. وقد يكون العميل متوافقاً لكنه لم يخرج بعد من فتح سابق. وقد تقع مشكلة بعد الملاحظة الصحيحة. ولكل حالة علاج مختلف.

التبني الاختياري يظهر كتوزيع لا كحكم واحد

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

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

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

السمة ليست حاجزاً أمنياً

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

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

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

المصادر