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

هذه الخيارات صالحة للاستخدام مع أي إصدار NFS.

nfsvers=n

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

vers=n

هذا الخيار هو بديل للخيار nfsvers. وقد ضُمّن للتوافق مع أنظمة التشغيل الأخرى

soft / softerr / hard

يحدد سلوك الاسترداد لعميل NFS بعد انتهاء مهلة طلب NFS. إذا لم يُحدد أي خيار (أو إذا حُدد الخيار hard)، تُعاد محاولة طلبات NFS إلى ما لا نهاية. إذا حُدد الخيار soft أو softerr، فإن عميل NFS يفشل في طلب NFS بعد إرسال عدد retrans من إعادات الإرسال، مما يتسبب في إرجاع عميل NFS إما الخطأ EIO (للخيار soft) أو ETIMEDOUT (للخيار softerr) إلى التطبيق المستدعِي.

ملاحظة: يمكن أن يتسبب ما يسمى بانتهاء المهلة "الناعم" (soft) في تلف البيانات الصامت في حالات معينة. بناءً على ذلك، لا تستخدم الخيار soft أو softerr إلا عندما تكون استجابة العميل أكثر أهمية من سلامة البيانات. وقد يؤدي استخدام NFS عبر TCP أو زيادة قيمة الخيار retrans إلى التخفيف من بعض مخاطر استخدام الخيار soft أو softerr.

softreval / nosoftreval

في الحالات التي يكون فيها خادم NFS متوقفًا، قد يكون من المفيد السماح لعميل NFS بالاستمرار في تقديم المسارات والسمات من الخبيئة بعد انتهاء مهلة محاولات retrans لإعادة التحقق من صحة تلك الخبيئة. قد يكون هذا، على سبيل المثال، مفيدًا عند محاولة فصل شجرة نظام ملفات من خادم متوقف نهائيًا.

يمكن دمج softreval مع خيار الوصل soft، وفي هذه الحالة ستنتهي مهلة العمليات التي لا يمكن تقديمها من الخبيئة وترجع خطأً بعد محاولات retrans. ويعني دمجها مع خيار الوصل المبدئي hard أن تلك العمليات غير المخبوءة ستستمر في إعادة المحاولة حتى تُستقبل استجابة من الخادم.

ملاحظة: خيار الوصل المبدئي هو nosoftreval الذي يمنع التراجع إلى الخبيئة عند فشل إعادة التحقق من الصحة، ويتبع بدلاً من ذلك السلوك الذي يمليه خيار الوصل hard أو soft.

intr / nointr

وُفر هذا الخيار للتوافق مع الإصدارات السابقة. ويُتجاهل بعد النواة 2.6.25.

timeo=n

الوقت بالثواني العشرية (أعشار الثانية) الذي ينتظره عميل NFS للاستجابة قبل إعادة محاولة طلب NFS.

بالنسبة لـ NFS عبر TCP، فإن قيمة timeo المبدئية هي 600 (60 ثانية). يقوم عميل NFS بتراجع خطي: بعد كل إعادة إرسال، تزداد مهلة الانتظار بمقدار timeo حتى حد أقصى يبلغ 600 ثانية.

ومع ذلك، بالنسبة لـ NFS عبر UDP، يستخدم العميل خوارزمية تكيفية لتقدير قيمة مهلة مناسبة لأنواع الطلبات المستخدمة بكثرة (مثل طلبات READ وWRITE)، ولكنه يستخدم إعداد timeo لأنواع الطلبات المستخدمة نادرًا (مثل طلبات FSINFO). إذا لم يُحدد خيار timeo، تُعاد محاولة أنواع الطلبات المستخدمة نادرًا بعد 1.1 ثانية. وبعد كل إعادة إرسال، يضاعف عميل NFS مهلة ذلك الطلب، حتى حد أقصى لطول المهلة يبلغ 60 ثانية.

أي قيمة timeo أكبر من القيمة المبدئية ستُضبط على القيمة المبدئية. بالنسبة لـ TCP وRDMA، القيمة المبدئية هي 600 (60 ثانية). بالنسبة لـ UDP، القيمة المبدئية هي 60 (6 ثوانٍ).

retrans=n

عدد المرات التي يعيد فيها عميل NFS محاولة الطلب قبل أن يحاول اتخاذ إجراء استرداد آخر. إذا لم يُحدد خيار retrans، يجرب عميل NFS كل طلب UDP ثلاث مرات وكل طلب TCP مرتين.

يولّد عميل NFS رسالة "الخادم لا يستجيب" بعد محاولات retrans، ثم يحاول إجراء المزيد من الاسترداد (اعتمادًا على ما إذا كان خيار الوصل hard قيد التشغيل).

rsize=n

الحد الأقصى لعدد البايتات في كل طلب شبكة READ يمكن لعميل NFS استقباله عند قراءة البيانات من ملف على خادم NFS. حجم حمولة البيانات الفعلية لكل طلب NFS READ يساوي إعداد rsize أو أقل منه. أكبر حمولة قراءة يدعمها عميل Linux NFS هي 1,048,576 بايت (ميغابايت واحد).

قيمة rsize المسموح بها هي مضاعف صحيح موجب لحجم صفحة النظام أو قوة للعدد اثنين إذا كانت أقل من حجم صفحة النظام. تُستبدل قيم rsize المحددة الأقل من 1024 بالقيمة 4096؛ وتُستبدل القيم الأكبر من 1048576 بالقيمة 1048576. إذا كانت القيمة المحددة تقع ضمن النطاق المدعوم ولكنها ليست قيمة مسموحًا بها، تُقرب نزولاً إلى أقرب قيمة مسموح بها.

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

يظهر خيار الوصل rsize كما هو محدد في سطر أوامر mount(8) في الملف /etc/mtab. ومع ذلك، فإن قيمة rsize الفعلية التي تفاوض عليها العميل والخادم يُبلغ عنها في الملف /proc/mounts.

wsize=n

الحد الأقصى لعدد البايتات لكل طلب شبكة WRITE يمكن لعميل NFS إرساله عند كتابة البيانات إلى ملف على خادم NFS. حجم حمولة البيانات الفعلية لكل طلب NFS WRITE يساوي إعداد wsize أو أقل منه. أكبر حمولة كتابة يدعمها عميل Linux NFS هي 1,048,576 بايت (ميغابايت واحد).

على غرار rsize، فإن قيمة wsize المسموح بها هي مضاعف صحيح موجب لحجم صفحة النظام أو قوة للعدد اثنين إذا كانت أقل من حجم صفحة النظام. تُستبدل قيم wsize المحددة الأقل من 1024 بالقيمة 4096؛ وتُستبدل القيم الأكبر من 1048576 بالقيمة 1048576. إذا كانت القيمة المحددة تقع ضمن النطاق المدعوم ولكنها ليست قيمة مسموحًا بها، تُقرب نزولاً إلى أقرب قيمة مسموح بها.

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

يظهر خيار الوصل wsize كما هو محدد في سطر أوامر mount(8) في الملف /etc/mtab. ومع ذلك، فإن قيمة wsize الفعلية التي تفاوض عليها العميل والخادم يُبلغ عنها في الملف /proc/mounts.

ac / noac

يحدد ما إذا كان بإمكان العميل تخزين سمات الملفات في الخبيئة. إذا لم يُحدد أي من الخيارين (أو إذا حُدد ac)، يقوم العميل بتخزين سمات الملفات في الخبيئة.

لتحسين الأداء، تخزن عملاء NFS سمات الملفات في الخبيئة. كل بضع ثوانٍ، يفحص عميل NFS نسخة الخادم من سمات كل ملف بحثًا عن تحديثات. التغييرات التي تحدث على الخادم في تلك الفترات الزمنية الصغيرة تظل غير مكتشفة حتى يفحص العميل الخادم مرة أخرى. يمنع الخيار noac العملاء من تخزين سمات الملفات في الخبيئة حتى تتمكن التطبيقات من اكتشاف تغييرات الملفات على الخادم بسرعة أكبر.

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

يوفر استخدام الخيار noac تماسكًا أكبر للخبيئة بين عملاء NFS الذين يصلون إلى الملفات نفسها، ولكنه يفرض عقوبة أداء كبيرة. وعلى هذا النحو، يُشجع على الاستخدام الحكيم لقفل الملفات بدلاً من ذلك. يحتوي قسم DATA AND METADATA COHERENCE على مناقشة مفصلة لهذه المقايضات.

acregmin=n

الحد الأدنى للوقت (بالثواني) الذي يخزن فيه عميل NFS سمات ملف عادي في الخبيئة قبل أن يطلب معلومات سمات جديدة من الخادم. إذا لم يُحدد هذا الخيار، يستخدم عميل NFS حدًا أدنى يبلغ 3 ثوانٍ. انظر قسم DATA AND METADATA COHERENCE لمناقشة كاملة حول تخزين السمات في الخبيئة.

acregmax=n

الحد الأقصى للوقت (بالثواني) الذي يخزن فيه عميل NFS سمات ملف عادي في الخبيئة قبل أن يطلب معلومات سمات جديدة من الخادم. إذا لم يُحدد هذا الخيار، يستخدم عميل NFS حدًا أقصى يبلغ 60 ثانية. انظر قسم DATA AND METADATA COHERENCE لمناقشة كاملة حول تخزين السمات في الخبيئة.

acdirmin=n

الحد الأدنى للوقت (بالثواني) الذي يخزن فيه عميل NFS سمات دليل في الخبيئة قبل أن يطلب معلومات سمات جديدة من الخادم. إذا لم يُحدد هذا الخيار، يستخدم عميل NFS حدًا أدنى يبلغ 30 ثانية. انظر قسم DATA AND METADATA COHERENCE لمناقشة كاملة حول تخزين السمات في الخبيئة.

acdirmax=n

الحد الأقصى للوقت (بالثواني) الذي يخزن فيه عميل NFS سمات دليل في الخبيئة قبل أن يطلب معلومات سمات جديدة من الخادم. إذا لم يُحدد هذا الخيار، يستخدم عميل NFS حدًا أقصى يبلغ 60 ثانية. انظر قسم DATA AND METADATA COHERENCE لمناقشة كاملة حول تخزين السمات في الخبيئة.

actimeo=n

يؤدي استخدام actimeo إلى ضبط كل من acregmin وacregmax وacdirmin وacdirmax على القيمة نفسها. إذا لم يُحدد هذا الخيار، يستخدم عميل NFS القيم المبدئية لكل من هذه الخيارات المذكورة أعلاه.

bg / fg

يحدد سلوك الأمر mount(8) إذا فشلت محاولة وصل تصدير. يتسبب الخيار fg في خروج mount(8) بحالة خطأ إذا انتهت مهلة أي جزء من طلب الوصل أو فشل تمامًا. يسمى هذا بالوصل في "الواجهة الأمامية"، وهو السلوك المبدئي إذا لم يُحدد أي من خياري الوصل fg أو bg.

إذا حُدد الخيار bg، فإن انتهاء المهلة أو الفشل يتسبب في قيام الأمر mount(8) بتفريع عملية ابن تستمر في محاولة وصل التصدير. وترجع العملية الأب فورًا برمز خروج صفر. يُعرف هذا بالوصل في "الخلفية".

إذا كان دليل نقطة الوصل المحلي مفقودًا، يتصرف الأمر mount(8) كما لو أن مهلة طلب الوصل قد انتهت. يسمح هذا لوصلات NFS المتداخلة المحددة في /etc/fstab بالمضي قدمًا بأي ترتيب أثناء تهيئة النظام، حتى لو لم تكن بعض خوادم NFS متاحة بعد. بدلاً من ذلك، يمكن معالجة هذه المشكلات باستخدام موصل آلي (راجع automount(8) للحصول على التفاصيل).

nconnect=n

عند استخدام بروتوكول موجه للاتصال مثل TCP، قد يكون من المفيد أحيانًا إعداد اتصالات متعددة بين العميل والخادم. على سبيل المثال، إذا كانت أجهزة العميل و/أو الخوادم لديك مجهزة ببطاقات واجهة شبكة متعددة (NICs)، فإن استخدام اتصالات متعددة لتوزيع الحمل قد يحسن الأداء العام. في مثل هذه الحالات، يتيح الخيار nconnect للمستخدم تحديد عدد الاتصالات التي ينبغي إنشاؤها بين العميل والخادم بما يصل إلى حد أقصى يبلغ 16.

لاحظ أن الخيار nconnect قد يُستخدم أيضًا بواسطة بعض برامج تشغيل pNFS لتحديد عدد الاتصالات التي ينبغي إعدادها لخوادم البيانات.

rdirplus / nordirplus

يحدد ما إذا كان سيتم استخدام طلبات NFS v3 أو v4 READDIRPLUS. إذا لم يُحدد هذا الخيار، يستخدم عميل NFS طريقة الكشف لتحسين الأداء باختيار READDIR مقابل READDIRPLUS بناءً على عدد المرات التي تستخدم فيها العملية المستدعِية السمات الإضافية المُرجعة من READDIRPLUS. تعمل بعض التطبيقات بشكل أفضل إذا استخدم العميل طلبات READDIR فقط لجميع الأدلة.

rdirplus={none|force}

إذا ضُبط على "force"، يحاول عميل NFS دائمًا استخدام طلبات READDIRPLUS. وإذا ضُبط على "none"، يكون السلوك هو نفسه سلوك nordirplus.

retry=n

عدد الدقائق التي يعيد فيها الأمر mount(8) محاولة عملية وصل NFS في الواجهة الأمامية أو الخلفية قبل الاستسلام. إذا لم يُحدد هذا الخيار، فإن القيمة المبدئية للوصلات في الواجهة الأمامية هي دقيقتان، والقيمة المبدئية للوصلات في الخلفية هي 10000 دقيقة (أقل بـ 80 دقيقة من أسبوع واحد). إذا حُددت قيمة الصفر، يخرج الأمر mount(8) فورًا بعد الفشل الأول.

لاحظ أن هذا يؤثر فقط على عدد محاولات الإعادة ولا يؤثر على التأخير الناجم عن كل محاولة. بالنسبة لـ UDP، تستغرق كل محاولة الوقت المحدد بواسطة خياري timeo وretrans، والذي سيكون افتراضيًا حوالي 7 ثوانٍ. بالنسبة لـ TCP، القيمة المبدئية هي 3 دقائق، ولكن مهلات اتصال TCP الخاصة بالنظام ستحد أحيانًا من مهلة كل إعادة إرسال إلى حوالي دقيقتين.

sec=flavors

قائمة مفصولة بنقطتين رئيسيتين لنوع أمني واحد أو أكثر لاستخدامها في الوصول إلى الملفات في التصدير الموصول. إذا كان الخادم لا يدعم أيًا من هذه الأنواع، تفشل عملية الوصل. إذا لم يُحدد sec=، يحاول العميل العثور على نوع أمني يدعمه كل من العميل والخادم. الأنواع (flavors) الصالحة هي none وsys وkrb5 وkrb5i وkrb5p. راجع قسم SECURITY CONSIDERATIONS للحصول على التفاصيل.

sharecache / nosharecache

يحدد كيفية مشاركة خبيئة بيانات العميل وخبيئة السمات عند وصل التصدير نفسه أكثر من مرة في الوقت نفسه. يؤدي استخدام الخبيئة نفسها إلى تقليل متطلبات الذاكرة على العميل ويوفر محتويات ملفات متطابقة للتطبيقات عند الوصول إلى الملف البعيد نفسه عبر نقاط وصل مختلفة.

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

بدءًا من النواة 2.6.18، يُعد السلوك المحدد بواسطة nosharecache سلوك تخزين مؤقت موروثًا (قديمًا). ويُعتبر هذا خطرًا على البيانات لأن نسخًا مخبوءة متعددة من الملف نفسه على العميل نفسه يمكن أن تصبح غير متزامنة بعد تحديث محلي لإحدى النسخ.

resvport / noresvport

يحدد ما إذا كان ينبغي لعميل NFS استخدام منفذ مصدر ذي امتيازات عند الاتصال بخادم NFS لنقطة الوصل هذه. إذا لم يُحدد هذا الخيار، أو حُدد الخيار resvport، يستخدم عميل NFS منفذ مصدر ذي امتيازات. وإذا حُدد الخيار noresvport، يستخدم عميل NFS منفذ مصدر ليس له امتيازات. هذا الخيار مدعوم في الأنوية 2.6.28 والأحدث.

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

راجع قسم SECURITY CONSIDERATIONS للحصول على تفاصيل مهمة.

lookupcache=mode

يحدد كيفية إدارة النواة لخبيئتها من إدخالات الدليل لنقطة وصل معينة. يمكن أن يكون الوضع (mode) أحد القيم all أو none or pos أو positive. هذا الخيار مدعوم في الأنوية 2.6.28 والأحدث.

يخزن عميل Linux NFS نتيجة جميع طلبات NFS LOOKUP في الخبيئة. إذا كان إدخال الدليل المطلوب موجودًا على الخادم، يُشار إلى النتيجة باسم إيجابي (positive). وإذا كان إدخال الدليل المطلوب غير موجود على الخادم، يُشار إلى النتيجة باسم سلبي (negative).

إذا لم يُحدد هذا الخيار، أو إذا حُدد all، يفترض العميل أن كلا النوعين من إدخالات خبيئة الدليل صالحة حتى تنتهي صلاحية السمات المخبوءة للدليل الأب.

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

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

يحتوي قسم DATA AND METADATA COHERENCE على مناقشة مفصلة لهذه المقايضات.

fsc / nofsc

يُمكّن/يُعطّل خبيئة صفحات البيانات (للقراءة فقط) على القرص المحلي باستخدام ميزة FS-Cache. انظر cachefilesd(8) و <kernel_source>/Documentation/filesystems/caching لمعرفة تفاصيل حول كيفية ضبط ميزة FS-Cache. القيمة المبدئية هي nofsc.

sloppy

الخيار sloppy هو بديل لتحديد الخيار mount.nfs -s option.

xprtsec=policy

يحدد استخدام أمن طبقة النقل لحماية حركة مرور شبكة NFS نيابة عن نقطة الوصل هذه. يمكن أن تكون السياسة (policy) واحدة من none أو tls أو mtls.

إذا حُدد none، يُعطل أمن طبقة النقل قسرًا، حتى لو كان خادم NFS يدعم أمن طبقة النقل.

إذا حُدد tls، يستخدم العميل RPC-with-TLS لتوفير السرية أثناء النقل.

إذا حُدد mtls، يستخدم العميل RPC-with-TLS ليستوثق من نفسه ولتوفير السرية أثناء النقل.

إذا حُدد tls أو mtls وكان الخادم لا يدعم RPC-with-TLS أو فشل استيثاق النظير، تفشل محاولة الوصل.

إذا لم يُحدد الخيار xprtsec=، يعتمد السلوك المبدئي على إصدار النواة، ولكنه يعادل عادةً xprtsec=none.

noalignwrite

يعطل هذا الخيار السلوك المبدئي المتمثل في تمديد عمليات الكتابة المخبوءة مؤقتًا إلى حدود كامل الصفحة.

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

خيارات للإصدارين 2 و3 من NFS فقط¶

استخدم هذه الخيارات، جنبًا إلى جنب مع الخيارات الموجودة في القسم الفرعي أعلاه، للإصدارين 2 و3 من NFS فقط.

proto=netid

يحدد معرف الشبكة (netid) وسيلة النقل المستخدمة للاتصال بخادم NFS. الخيارات المتاحة هي udp وudp6 وtcp وtcp6 وrdma وrdma6. تلك التي تنتهي بالرقم 6 تستخدم عناوين IPv6 ولا تتوفر إلا إذا كان الدعم لـ TI-RPC مدمجًا. وتستخدم الخيارات الأخرى عناوين IPv4.

يستخدم كل بروتوكول نقل إعدادات retrans وtimeo مبدئية مختلفة. راجع وصف هذين الخيارين للوصل للحصول على التفاصيل.

بالإضافة إلى التحكم في كيفية إرسال عميل NFS للطلبات إلى الخادم، يتحكم خيار الوصل هذا أيضًا في كيفية اتصال الأمر mount(8) بخدمات rpcbind وmountd الخاصة بالخادم. يؤدي تحديد netid يستخدم TCP إلى إجبار جميع حركات المرور من الأمر mount(8) وعميل NFS على استخدام TCP. يؤدي تحديد netid يستخدم UDP إلى إجبار جميع أنواع حركات المرور على استخدام UDP.

قبل استخدام NFS عبر UDP، راجع قسم TRANSPORT METHODS.

إذا لم يُحدد خيار الوصل proto، يكتشف الأمر mount(8) البروتوكولات التي يدعمها الخادم ويختار وسيلة نقل مناسبة لكل خدمة. راجع قسم TRANSPORT METHODS لمزيد من التفاصيل.

udp

الخيار udp هو بديل لتحديد proto=udp.. وقد ضُمّن للتوافق مع أنظمة التشغيل الأخرى.

قبل استخدام NFS عبر UDP، راجع قسم TRANSPORT METHODS.

tcp

الخيار tcp هو بديل لتحديد proto=tcp.. وقد ضُمّن للتوافق مع أنظمة التشغيل الأخرى.

rdma

الخيار rdma هو بديل لتحديد proto=rdma.

port=n

القيمة الرقمية لمنفذ خدمة NFS الخاص بالخادم. إذا كانت خدمة NFS الخاصة بالخادم غير متاحة على المنفذ المحدد، يفشل طلب الوصل.

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

mountport=n

القيمة الرقمية لمنفذ mountd الخاص بالخادم. إذا كانت خدمة mountd الخاصة بالخادم غير متاحة على المنفذ المحدد، يفشل طلب الوصل.

إذا لم يُحدد هذا الخيار، أو إذا كانت قيمة المنفذ المحددة هي 0، فإن الأمر mount(8) يستخدم رقم منفذ خدمة mountd المعلن عنه بواسطة خدمة rpcbind الخاصة بالخادم. يفشل طلب الوصل إذا كانت خدمة rpcbind الخاصة بالخادم غير متاحة، أو إذا كانت خدمة mountd الخاصة بالخادم غير مسجلة في خدمة rpcbind الخاصة بها، أو إذا كانت خدمة mountd الخاصة بالخادم غير متاحة على المنفذ المعلن عنه.

يمكن استخدام هذا الخيار عند وصل خادم NFS عبر جدار حماية يحظر بروتوكول rpcbind.

mountproto=netid

وسيلة النقل التي يستخدمها عميل NFS لإرسال الطلبات إلى خدمة mountd الخاصة بخادم NFS عند تنفيذ طلب الوصل هذا، وعند فصل نقطة الوصل هذه لاحقًا.

قد يكون معرف الشبكة (netid) أحد الخيارات udp وtcp التي تستخدم عنوان IPv4، أو إذا كان TI-RPC مدمجًا في الأمر mount.nfs، فقد يكون udp6 وtcp6 اللذين يستخدمان عناوين IPv6.

يمكن استخدام هذا الخيار عند وصل خادم NFS عبر جدار حماية يحظر وسيلة نقل معينة. عند استخدامه بالدمج مع الخيار proto، يمكن تحديد وسائل نقل مختلفة لطلبات mountd وطلبات NFS. إذا كانت خدمة mountd الخاصة بالخادم غير متاحة عبر وسيلة النقل المحددة، يفشل طلب الوصل.

راجع قسم TRANSPORT METHODS لمزيد من المعلومات حول كيفية تفاعل خيار الوصل mountproto مع خيار الوصل proto.

mounthost=name

اسم مضيف المضيف الذي يشغّل mountd. إذا لم يُحدد هذا الخيار، يفترض الأمر mount(8) أن خدمة mountd تعمل على المضيف نفسه الذي تعمل عليه خدمة NFS.

mountvers=n

رقم إصدار RPC المستخدم للاتصال بـ mountd الخاص بالخادم. إذا لم يُحدد هذا الخيار، يستخدم العميل رقم إصدار مناسبًا لإصدار NFS المطلوب. هذا الخيار مفيد عندما تعمل خدمات NFS متعددة على مضيف الخادم البعيد نفسه.

namlen=n

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

لم تكن بعض الإصدارات المبكرة من NFS تدعم هذا التفاوض. يضمن استخدام هذا الخيار أن يبلغ pathconf(3) عن الحد الأقصى الصحيح لمكون الطول للتطبيقات في مثل هذه الحالات.

lock / nolock

يحدد ما إذا كان سيتم استخدام بروتوكول النطاق الجانبي NLM لقفل الملفات على الخادم. إذا لم يُحدد أي من الخيارين (أو إذا حُدد lock)، يُستخدم قفل NLM لنقطة الوصل هذه. عند استخدام الخيار nolock، يمكن للتطبيقات قفل الملفات، ولكن مثل هذه الأقفال توفر استبعادًا فقط ضد التطبيقات الأخرى التي تعمل على العميل نفسه. ولا تتأثر التطبيقات البعيدة بهذه الأقفال.

يجب تعطيل قفل NLM باستخدام الخيار nolock عند استخدام NFS لوصل /var لأن /var يحتوي على ملفات تستخدمها أداة NLM على لينكس. كما يُشترط استخدام الخيار nolock عند وصل الصادرات على خوادم NFS التي لا تدعم بروتوكول NLM.

cto / nocto

يحدد ما إذا كان سيُستخدم دلالات تماسك الخبيئة من نوع close-to-open (الإغلاق للفتح). إذا لم يُحدد أي من الخيارين (أو إذا حُدد cto)، يستخدم العميل دلالات تماسك خبيئة close-to-open. وإذا حُدد الخيار nocto، يستخدم العميل أسلوبًا استكشافيًا غير قياسي لتحديد وقت تغير الملفات على الخادم.

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

acl / noacl

يحدد ما إذا كان سيُستخدم بروتوكول النطاق الجانبي NFSACL على نقطة الوصل هذه. بروتوكول النطاق الجانبي NFSACL هو بروتوكول مملوك ومطبق في سولاريس يدير قوائم التحكم في الوصول. ولم يُجعل NFSACL جزءًا قياسيًا من مواصفات بروتوكول NFS على الإطلاق.

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

local_lock=mechanism

يحدد ما إذا كان سيُستخدم القفل المحلي لآلية flock أو آلية POSIX أو كلتيهما. يمكن أن تكون mechanism أحد الخيارات all أو flock أو posix أو none. هذا الخيار مدعوم في النوى 2.6.37 والأحدث.

يوفر عميل Linux NFS طريقة لجعل الأقفال محلية. هذا يعني أنه يمكن للتطبيقات قفل الملفات، ولكن مثل هذه الأقفال توفر استبعادًا فقط ضد التطبيقات الأخرى التي تعمل على العميل نفسه. لا تتأثر التطبيقات البعيدة بهذه الأقفال.

إذا لم يُحدد هذا الخيار، أو إذا حُدد none، يفترض العميل أن الأقفال ليست محلية.

إذا حُدد all، يفترض العميل أن أقفال flock و POSIX محلية.

إذا حُدد flock، يفترض العميل أن أقفال flock فقط محلية ويستخدم بروتوكول النطاق الجانبي NLM لقفل الملفات عند استخدام أقفال POSIX.

إذا حُدد posix، يفترض العميل أن أقفال POSIX محلية ويستخدم بروتوكول النطاق الجانبي NLM لقفل الملفات عند استخدام أقفال flock.

لدعم سلوك flock القديم المماثل لعملاء NFS الأقدم من 2.6.12، استخدم 'local_lock=flock'. هذا الخيار مطلوب عند تصدير عمليات وصل NFS عبر Samba حيث يطابق Samba أقفال وضع المشاركة في Windows كأقفال flock. نظرًا لأن عملاء NFS الأحدث من 2.6.12 يطبقون flock عن طريق محاكاة أقفال POSIX، فسيؤدي ذلك إلى تضارب في الأقفال.

ملاحظة: عند استخدامهما معًا، سيُلغى خيار الوصل 'local_lock' بواسطة خيار الوصل 'nolock'/'lock'.

خيارات للإصدار 4 من NFS فقط¶

استخدم هذه الخيارات، جنبًا إلى جنب مع الخيارات الموجودة في القسم الفرعي الأول أعلاه، للإصدار 4.0 من NFS والأحدث.

proto=netid

يحدد netid النقل المستخدم للتراسل مع خادم NFS. الخيارات المدعومة هي tcp و tcp6 و rdma و rdma6. يستخدم tcp6 عناوين IPv6 وهو متاح فقط إذا كان دعم TI-RPC مدمجًا. ويستخدم الآخران عناوين IPv4.

يُشترط على جميع خوادم الإصدار 4 من NFS دعم TCP، لذلك إذا لم يُحدد خيار الوصل هذا، يستخدم عميل الإصدار 4 من NFS بروتوكول TCP. راجع قسم طرق النقل لمزيد من التفاصيل.

minorversion=n

يحدد رقم الإصدار الفرعي للبروتوكول. يقدم NFSv4 "الإصدار الفرعي"، حيث يمكن تقديم تحسينات بروتوكول NFS دون رفع رقم إصدار بروتوكول NFS. قبل النواة 2.6.38، يكون الإصدار الفرعي دائمًا صفرًا، ولا يُتعرف على هذا الخيار. بعد هذه النواة، يؤدي تحديد "minorversion=1" إلى تمكين عدد من الميزات المتقدمة، مثل جلسات NFSv4.

تسمح النوى الحديثة بتحديد الإصدار الفرعي باستخدام الخيار vers=. على سبيل المثال، تحديد vers=4.1 هو نفس تحديد vers=4,minorversion=1.

port=n

القيمة الرقمية لمنفذ خدمة NFS الخاص بالخادم. إذا كانت خدمة NFS الخاصة بالخادم غير متاحة على المنفذ المحدد، يفشل طلب الوصل.

إذا لم يُحدد خيار الوصل هذا، يستخدم عميل NFS رقم منفذ NFS القياسي 2049 دون التحقق أولاً من خدمة rpcbind الخاصة بالخادم. يتيح ذلك لعميل الإصدار 4 من NFS متراسلة خادم الإصدار 4 من NFS عبر جدار حماية قد يحظر طلبات rpcbind.

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

cto / nocto

يحدد ما إذا كان سيُستخدم دلالات تماسك خبيئة close-to-open لدلائل NFS على نقطة الوصل هذه. إذا لم يُحدد cto ولا nocto، فإن المبدئي هو استخدام دلالات تماسك خبيئة close-to-open للدلائل.

لا يتأثر سلوك خبأ بيانات الملف بهذا الخيار. يناقش قسم تماسك البيانات والبيانات الوصفية سلوك هذا الخيار بمزيد من التفصيل.

clientaddr=n.n.n.n

clientaddr=n:n:...:n

يحدد عنوان IPv4 واحدًا (في شكل رباعي منقط)، أو عنوان IPv6 غير محلي للوصلة، يعلن عنه عميل NFS لكي يسمح للخوادم بتنفيذ طلبات رد النداء للإصدار 4.0 من NFS مقابل الملفات على نقطة الوصل هذه. إذا لم يتمكن الخادم من إنشاء اتصالات رد نداء بالعملاء، فقد يتدهور الأداء، أو قد يتوقف الوصول إلى الملفات مؤقتًا. يمكن تحديد قيمة IPv4_ANY (0.0.0.0) أو ما يعادلها من عنوان IPv6 لإرسال إشارة إلى خادم NFS بأن عميل NFS هذا لا يريد تفويضات.

إذا لم يُحدد هذا الخيار، يحاول الأمر mount(8) اكتشاف عنوان رد نداء مناسب آليًا. ومع ذلك، فإن عملية الاكتشاف الآلي ليست مثالية. في وجود واجهات شبكة متعددة للعميل، أو سياسات توجيه خاصة، أو توبولوجيا شبكة غير نمطية، قد يكون تحديد العنوان الدقيق لاستخدامه لردود النداء أمرًا غير بسيط.

تستخدم إصدارات بروتوكول NFS 4.1 و 4.2 اتصال TCP الذي أنشأه العميل لطلبات رد النداء، لذا لا تتطلب من الخادم الاتصال بالعميل. لذلك، يؤثر هذا الخيار فقط على عمليات وصل الإصدار 4.0 من NFS.

migration / nomigration

يحدد ما إذا كان العميل يستخدم سلسلة تعريف متوافقة مع هجرة الحالة الشفافة لـ NFSv4 (TSM). إذا كان الخادم الموصول يدعم هجرة NFSv4 مع TSM، فحدد الخيار migration.

تسيء بعض ميزات الخادم السلوك في مواجهة سلسلة تعريف متوافقة مع الهجرة. يحتفظ الخيار nomigration باستخدام سلسلة تعريف عميل تقليدية متوافقة مع خوادم NFS القديمة. هذا هو السلوك أيضًا إذا لم يُحدد أي من الخيارين. لا يمكن هجرة حالة الفتح والقفل للعميل بشكل شفاف عندما يعرف نفسه عبر سلسلة تعريف تقليدية.

ليس لخيار الوصل هذا أي تأثير مع الإصدارات الفرعية لـ NFSv4 الأحدث من الصفر، والتي تستخدم دائمًا سلاسل تعريف عميل متوافقة مع TSM.

max_connect=n

بينما يضع الخيار nconnect حدًا لعدد الاتصالات التي يمكن إنشاؤها لعنوان IP معين للخادم، فإن الخيار max_connect يسمح للمستخدم بتحديد الحد الأقصى لعدد الاتصالات بعناوين IP المختلفة للخادم والتي تنتمي إلى خادم NFSv4.1+ نفسه (اتصالات قابلة للتجميع في جلسة) بحد أقصى 16 اتصالاً. عندما يكتشف العميل أنه أنشأ معرف عميل لخادم موجود بالفعل، فبدلاً من إسقاط النقل الشبكي المنشأ حديثًا، سيضيف العميل هذا الاتصال الجديد إلى قائمة وسائل النقل المتاحة لعميل RPC ذاك.

trunkdiscovery / notrunkdiscovery

عندما يكتشف العميل نظام ملفات جديدًا على خادم NFSv4.1+، فإن خيار الوصل trunkdiscovery سيجعله يرسل طلب GETATTR لخاصية fs_locations. إذا تلقى ردًا بطول غير صفري، فسوف يمر عبر الاستجابة تكراريًا، وللإشارة إلى كل موقع خادم سينشئ اتصالاً، ويرسل EXCHANGE_ID، ويختبر تجميع الجلسة. إذا نجح اختبار التجميع، فسيُضاف الاتصال إلى المجموعة الحالية من وسائل النقل للخادم، شريطة الالتزام بالحد المحدد بواسطة الخيار max_connect. المبدئي هو notrunkdiscovery.

استخدام خيار الوصل mountproto¶

ينطبق هذا القسم فقط على عمليات وصل الإصدار 3 من NFS نظراً لأن الإصدار 4 من NFS لا يستخدم بروتوكولاً منفصلاً لطلبات الوصل.

يمكن لعميل Linux NFS استخدام وسيلة نقل مختلفة لمتراسلة خدمة rpcbind لخادم NFS، وخدمة mountd الخاصة به، وخدمة مدير القفل الشبكي (NLM) الخاصة به، وخدمة NFS الخاصة به. تعتمد وسائل النقل الدقيقة التي يوظفها عميل Linux NFS لكل نقطة وصل على إعدادات خيارات وصل النقل، والتي تشمل proto و mountproto و udp و tcp.

يرسل العميل إشعارات مدير حالة الشبكة (NSM) عبر UDP بغض النظر عن خيارات النقل المحددة، ولكنه يستمع إلى إشعارات NSM الخاصة بالخادم على كل من UDP و TCP. يتشارك بروتوكول قائمة التحكم في الوصول إلى NFS (NFSACL) نفس وسيلة النقل مع خدمة NFS الرئيسة.

إذا لم تُحدد خيارات نقل، يستخدم عميل Linux NFS بروتوكول UDP لمتراسلة خدمة mountd الخاصة بالخادم، و TCP لمتراسلة خدمتي NLM و NFS مبدئيًا.

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

عند تحديد الخيار proto أو الخيار udp أو الخيار tcp دون تحديد الخيار mountproto، تُستخدم وسيلة النقل المحددة لمتراسلة خدمة mountd الخاصة بالخادم وكذلك لخدمات NLM و NFS.

إذا حدد الخيار mountproto ولكن لم يُحدد أي من الخيارات proto أو udp أو tcp، تُستخدم وسيلة النقل المحددة لطلب mountd المبدئي، ولكن يحاول أمر الوصل اكتشاف ما يدعمه الخادم لبروتوكول NFS، مع تفضيل TCP إذا كانت كلتا وسيلتي النقل مدعومتين.

إذا حُدد كلا الخيارين mountproto و proto (أو udp أو tcp)، تُستخدم وسيلة النقل المحددة بواسطة الخيار mountproto لطلب mountd المبدئي، وتُستخدم وسيلة النقل المحددة بواسطة الخيار proto (أو الخيارين udp أو tcp) لـ NFS، بغض النظر عن الترتيب الذي تظهر به هذه الخيارات. ولا يُجرى أي اكتشاف آلي للخدمة إذا حُددت هذه الخيارات.

إذا حُدد أي من الخيارات proto أو udp أو tcp أو mountproto أكثر من مرة على سطر أوامر الوصل نفسه، فإن قيمة الحالة الواقعة في أقصى اليمين من كل خيار من هذه الخيارات هي التي تسري.

استخدام NFS عبر UDP على الوصلات عالية السرعة¶

إن استخدام NFS عبر UDP على الوصلات عالية السرعة مثل غيغابايت يمكن أن يسبب فسادًا صامتًا للبيانات.

يمكن أن تُثار المشكلة عند الأحمال العالية، وسببها مشكلات في إعادة تجميع أجزاء IP. عادةً ما تنقل عمليات قراءة وكتابة NFS حزم UDP بحجم 4 كيلوبايت أو أكثر، والتي يجب تقسيمها إلى عدة أجزاء لإرسالها عبر وصلة الإيثرنت، والتي تحصر الحزم في 1500 بايت مبدئيًا. تحدث هذه العملية في طبقة شبكة IP وتسمى التجزئة.

من أجل تحديد الأجزاء التي تنتمي لبعضها البعض، يخصص IP قيمة IP ID بحجم 16 بت لكل حزمة؛ والأجزاء الناتجة عن حزمة UDP نفسها سيكون لها نفس معرّف IP ID. يجمع النظام المستقبل هذه الأجزاء ويضمها لتشكيل حزمة UDP الأصلية. تسمى هذه العملية إعادة التجميع. مهلة الاستراحة المبدئية لإعادة تجميع الحزم هي 30 ثانية؛ وإذا لم يتلقَ مكدس الشبكة جميع أجزاء حزمة معينة خلال هذه الفترة، فإنه يفترض أن الجزء (الأجزاء) المفقود قد ضاع ويطرح الأجزاء التي استقبلها بالفعل.

المشكلة التي يخلقها هذا عبر الوصلات عالية السرعة هي أنه من الممكن إرسال أكثر من 65536 حزمة في غضون 30 ثانية. في الواقع، مع حركة مرور NFS الكثيفة، يمكن للمرء أن يلاحظ تكرار معرفات IP بعد حوالي 5 ثوانٍ.

لهذا آثار خطيرة على إعادة التجميع: إذا فُقد جزء واحد، فسيصل جزء آخر من حزمة مختلفة ولكن مع معرف IP نفسه في غضون مهلة الـ 30 ثانية، وسيقوم مكدس الشبكة بدمج هذه الأجزاء لتشكيل حزمة جديدة. في معظم الأوقات، تكتشف طبقات الشبكة فوق IP إعادة التجميع غير المتطابقة هذه - في حالة UDP، فإن مجموع تدقيق UDP، وهو مجموع تدقيق 16 بت على حمولة الحزمة بأكملها، لن يتطابق عادةً، وسيطرح UDP الحزمة السيئة.

ومع ذلك، فإن مجموع تدقيق UDP هو 16 بت فقط، لذا هناك احتمال 1 من كل 65536 أن يتطابق حتى لو كانت حمولة الحزمة عشوائية تمامًا (وهو ما لا يحدث كثيرًا في الغالب). إذا كان الأمر كذلك، فسيحدث فساد صامت للبيانات.

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

لذلك يُوصى بشدة باستخدام NFS عبر TCP حيثما أمكن، لأن TCP لا يجرى تجزئة.

إذا كان عليك مطلقًا استخدام NFS عبر UDP عبر شبكة غيغابايت إيثرنت، فيمكن اتخاذ بعض الخطوات لتخفيف المشكلة وتقليل احتمالية الفساد:

Jumbo frames:

العديد من بطاقات شبكة غيغابايت قادرة على نقل إطارات أكبر من حد 1500 بايت للإيثرنت التقليدي، وعادة ما تكون 9000 بايت. سيتيح لك استخدام الإطارات العملاقة (jumbo frames) بحجم 9000 بايت تشغيل NFS عبر UDP بحجم صفحة يبلغ 8 كيلوبايت دون تجزئة. بالطبع، هذا غير ممكن إلا إذا كانت جميع المحطات المعنية تدعم الإطارات العملاقة.

لتمكين حاسوب من إرسال إطارات عملاقة على البطاقات التي تدعم ذلك، يكفي ضبط الواجهة لقيمة MTU تبلغ 9000.

Lower reassembly timeout:

من خلال خفض هذه المهلة إلى أقل من الوقت الذي يستغرقه عداد معرف IP للالتفاف، يمكن منع إعادة التجميع غير الصحيحة للأجزاء أيضًا. للقيام بذلك، ما عليك سوى كتابة قيمة المهلة الجديدة (بالثواني) في الملف /proc/sys/net/ipv4/ipfrag_time.

ستقلل قيمة ثانيتين بشكل كبير من احتمالية حدوث تضارب في معرّفات IPID على وصلة غيغابايت واحدة، مع الاستمرار في السماح بمهلة معقولة عند استقبال حركة مرور مجزأة من النظراء البعيدين.

اتساق خبيئة Close-to-open¶

عادةً ما تكون مشاركة الملفات تتابعية تمامًا. أولاً، يفتح العميل أ ملفًا، ويكتب شيئًا فيه، ثم يغلقه. ثم يفتح العميل ب الملف نفسه، ويقرأ التغييرات.

عندما يفتح تطبيق ملفًا مخزنًا على خادم الإصدار 3 من NFS، يتحقق عميل NFS من وجود الملف على الخادم ومسموح به للفاتح عن طريق إرسال طلب GETATTR أو ACCESS. يرسل عميل NFS هذه الطلبات بغض النظر عن مدى حداثة سمات الملف المخبأة.

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

يُشار إلى سلوك التحقق في وقت الفتح والدفق في وقت الإغلاق باسم اتساق خبيئة close-to-open، أو CTO. ويمكن تعطيله لنقطة وصل بأكملها باستخدام خيار الوصل nocto.

اتساق الخبيئة الضعيف¶

لا تزال هناك فرص لاحتواء خبيئة بيانات العميل على بيانات قديمة. قدم بروتوكول الإصدار 3 من NFS "اتساق الخبيئة الضعيف" (المعروف أيضًا باسم WCC) والذي يوفر طريقة للتحقق بكفاءة من سمات الملف قبل طلب واحد وبعده. يتيح ذلك للعميل المساعدة في تحديد التغييرات التي يمكن أن يكون قد أجراها عملاء آخرون.

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

خبأ السمات¶

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

احذر من الخلط بين خيار noac و "عدم خبأ البيانات". يمنع خيار الوصل noac العميل من خبأ البيانات الوصفية للملف، ولكن لا تزال هناك حالات تضارب (races) قد تؤدي إلى عدم تماسك خبيئة البيانات بين العميل والخادم.

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

صيانة الطوابع الزمنية للملف¶

خوادم NFS مسؤولة عن إدارة الطوابع الزمنية للملفات والدلائل (atime و ctime و mtime). عندما يُلوج إلى ملف أو يُحدث على خادم NFS، تُحدث الطوابع الزمنية للملف تمامًا كما يحدث على نظام ملفات محلي للتطبيق.

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

للامتثال لمعيار نظام ملفات POSIX، يعتمد عميل Linux NFS على خوادم NFS لإبقاء الطوابع الزمنية mtime و ctime للملف محدثة بشكل صحيح. ويقوم بذلك عن طريق دفق تغييرات البيانات المحلية إلى الخادم قبل إبلاغ التطبيقات بـ mtime عبر استدعاءات النظام مثل stat(2).

ومع ذلك، يتعامل عميل لينكس مع تحديثات atime بشكل أكثر تساهلاً. يحافظ عملاء NFS على أداء جيد عن طريق خبأ البيانات، ولكن هذا يعني أن قراءات التطبيق، التي تحدث عادةً atime، لا تنعكس على الخادم حيث يُصان atime للملف فعليًا.

بسبب سلوك الخبأ هذا، لا يدعم عميل Linux NFS خيارات الوصل العامة المتعلقة بـ atime. انظر mount(8) للحصول على تفاصيل حول هذه الخيارات.

على وجه الخصوص، ليس لخيارات الوصل atime/noatime و diratime/nodiratime و relatime/norelatime و strictatime/nostrictatime أي تأثير على عمليات وصل NFS.

قد يذكر /proc/mounts أن خيار الوصل relatime معين على عمليات وصل NFS، ولكن في الواقع دلالات atime هي دائمًا كما هو موصوف هنا، وليست مثل دلالات relatime.

خبأ مدخلات الدليل¶

يخبئ عميل Linux NFS نتيجة جميع طلبات NFS LOOKUP. إذا كان مدخل الدليل المطلوب موجودًا على الخادم، يُشار إلى النتيجة على أنها نتيجة بحث إيجابية. إذا كان مدخل الدليل المطلوب غير موجود على الخادم (أي أن الخادم أرجع ENOENT)، يُشار إلى النتيجة على أنها نتيجة بحث سلبية.

لاكتشاف وقت إضافة مدخلات الدليل أو إزالتها على الخادم، يراقب عميل Linux NFS قيمة mtime الخاصة بالدليل. إذا اكتشف العميل تغييرًا في mtime الخاص بالدليل، فإنه يسقط جميع نتائج LOOKUP المخبأة لذلك الدليل. نظرًا لأن mtime الخاص بالدليل هو سمة مخبأة، فقد يستغرق الأمر بعض الوقت قبل أن يلاحظ العميل أنه تغير. انظر أوصاف خيارات الوصل acdirmin و acdirmax و noac لمزيد من المعلومات حول مدة خبأ mtime الخاص بالدليل.

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

قبل إصدار النواة 2.6.28، كان عميل Linux NFS يتتبع نتائج البحث الإيجابية فقط. سمح هذا للتطبيقات باكتشاف مدخلات الدليل الجديدة التي أنشأها عملاء آخرون بسرعة مع الاستمرار في توفير بعض مزايا الأداء للخبأ. إذا كان التطبيق يعتمد على سلوك خبأ البحث السابق لعميل Linux NFS، فيمكنك استخدام lookupcache=positive.

إذا تجاهل العميل خبيئته وثبّت صحة كل طلب بحث من التطبيق مع الخادم، فيمكن لهذا العميل اكتشاف ما إذا أُنشئ مدخل دليل جديد أو أُزيل بواسطة عميل آخر فورًا. يمكنك تحديد هذا السلوك باستخدام lookupcache=none. قد تفرض طلبات NFS الإضافية المطلوبة إذا لم يخبئ العميل مدخلات الدليل عقوبة على الأداء. ينبغي أن يؤدي تعطيل تخبئة البحث إلى عقوبة أداء أقل من استخدام noac، وليس له أي تأثير في كيفية تخبئة عميل NFS لسمات الملفات.

خيار الوصل sync¶

يعامل عميل NFS خيار الوصل sync بشكل مختلف عن بعض أنظمة الملفات الأخرى (ارجع إلى mount(8) لوصف خيارات الوصل العمومية sync و async). إذا لم يُحدد أي من sync أو async (أو إذا حُدد الخيار async)، فإن عميل NFS يؤخر إرسال كتابات التطبيق إلى الخادم حتى يقع أي من هذه الأحداث:

ضغط الذاكرة يجبر استصلاح موارد ذاكرة النظام.

يدفق التطبيق بيانات الملف صراحةً باستخدام sync(2) أو msync(2) أو fsync(3).

يغلق التطبيق ملفًا باستخدام close(2).

يُقفل الملف أو يُلغى قفله عبر fcntl(2).

بعبارة أخرى، في الظروف العادية، قد لا تظهر البيانات التي يكتبها التطبيق فورًا على الخادم الذي يستضيف الملف.

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

يمكن للتطبيقات استخدام علم الفتح O_SYNC لإجبار كتابات التطبيق على ملفات فردية للذهاب إلى الخادم فورًا دون استخدام خيار الوصل sync.

استخدام أقفال الملفات مع NFS¶

بروتوكول مدير أقفال الشبكة (NLM) هو بروتوكول نطاق جانبي منفصل يُستخدم لإدارة أقفال الملفات في إصدارة NFS رقم 3. ولدعم استرداد القفل بعد إعادة تشغيل العميل أو الخادم، يلزم أيضًا بروتوكول نطاق جانبي ثانٍ -- يُعرف باسم بروتوكول مدير حالة الشبكة (NSM). في إصدارة NFS رقم 4، يُدعم قفل الملفات مباشرة في بروتوكول NFS الرئيس، ولا تُستخدم بروتوكولات النطاق الجانبي NLM و NSM.

في معظم الحالات، تُبدأ خدمات NLM و NSM آليًا، ولا يلزم أي ضبط إضافي. اضبط كل عملاء NFS بأسماء نطاقات مؤهلة بالكامل لضمان تمكن خوادم NFS من العثور على العملاء لإشعارهم بإعادة تشغيل الخادم.

يدعم NLM أقفال الملفات الاستشارية فقط. لقفل ملفات NFS، استخدم fcntl(2) مع الأمرَين F_GETLK و F_SETLK. يحوّل عميل NFS أقفال الملفات المستحصلة عبر flock(2) إلى أقفال استشارية.

عند وصل خوادم لا تدعم بروتوكول NLM، أو عند وصل خادم NFS عبر جدار حماية يحظر منفذ خدمة NLM، حدد خيار الوصل nolock. يجب تعطيل قفل NLM باستخدام الخيار nolock عند استخدام NFS لوصل /var لأن /var يحتوي على ملفات تُستخدم بواسطة تطبيق NLM على لينكس.

قد يُنصح أيضًا بتحديد الخيار nolock لتحسين أداء تطبيق احتكاري يعمل على عميل واحد ويستخدم أقفال الملفات بكثافة.

ميزات التخبئة في إصدارة NFS رقم 4¶

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

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

تفويض الملف هو عقد بين خادم وعميل إصدارة NFS رقم 4 يسمح للعميل بمعاملة الملف مؤقتًا كما لو أنه لا يوجد عميل آخر يصل إليه. يعد الخادم بإشعار العميل (عبر طلب استدعاء راجع) إذا حاول عميل آخر الوصول إلى هذا الملف. بمجرد تفويض الملف إلى عميل، يمكن للعميل تخبئة بيانات ذلك الملف وبياناته الوصفية بقوة دون مراسلة الخادم.

يأتي تفويض الملف بنوعين: قراءة و كتابة. يعني تفويض القراءة أن الخادم يُشعر العميل بأي عملاء آخرين يريدون الكتابة في الملف. ويعني تفويض الكتابة أن العميل يتلقى إشعارًا بشأن واصلي القراءة أو الكتابة.

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

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

عبور نظام ملفات إصدارة NFS رقم 4¶

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

يحدث هذا التفاوض عادةً عندما يعبر العميل من نظام ملفات وهمي (pseudo-fs) للخادم إلى أحد أنظمة الملفات المادية المصدرة للخادم، والتي غالبًا ما تحتوي على إعدادات أمنية أكثر تقييدًا من نظام الملفات الوهمي.

عقود إيجار إصدارة NFS رقم 4¶

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

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

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

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

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

عند ضبط كيربيروس على عميل لينكس NFS (أي وجود /etc/krb5.keytab على هذا العميل)، يحاول العميل استخدام تشكيلة أمن كيربيروس لعمليات إدارة عقد إيجاره. يوفر كيربيروس استيثاقًا آمنًا لكل عميل. مبدئيًا، يستخدم العميل أصيل خدمة host/ أو nfs/ في ملف /etc/krb5.keytab الخاص به لهذا الغرض، كما هو موصوف في rpc.gssd(8).

إذا كان العميل قد ضُبط فيه كيربيروس، ولكن الخادم لم يُضبط، أو إذا لم يكن لدى العميل جدول مفاتيح (keytab) أو أصلاء الخدمة المطلوبين، فيستخدم العميل AUTH_SYS ومعرّف المستخدم 0 لإدارة عقد الإيجار.

استخدام منافذ مصدر غير متميزة¶

عادةً ما يتراسل عملاء NFS مع خوادم NFS عبر مقابس الشبكة. يُعين لكل طرف من أطراف المقبس قيمة منفذ، وهي ببساطة رقم بين 1 و 65535 يميز نقاط نهاية المقبس عند نفس عنوان IP. يُعرَف المقبس بشكل فريد بواسطة صف يحتوي على بروتوكول النقل (TCP أو UDP) وقيم المنافذ وعناوين IP لكلا نقطتي النهاية.

يمكن لعميل NFS اختيار أي قيمة منفذ مصدر لمقابسه، ولكنه عادةً ما يختار منفذًا متميزًا. المنفذ المتميز هو قيمة منفذ أقل من 1024. يجوز فقط لعملية تتمتع بامتيازات الجذر (root) إنشاء مقبس بمنفذ مصدر متميز.

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

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

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

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

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

الوصل عبر جدار حماية¶

قد يقع جدار حماية بين عميل وخادم NFS، أو قد يحظر العميل أو الخادم بعض منافذه الخاصة عبر قواعد تصفية IP. لا يزال من الممكن وصل خادم NFS عبر جدار حماية، على الرغم من أن بعض آليات الاكتشاف الآلي لنقاط نهاية الخدمة لأمر mount(8) قد لا تعمل؛ يتطلب هذا منك تقديم تفاصيل محددة لنقطة النهاية عبر خيارات وصل NFS.

عادةً ما تشغّل خوادم NFS عفريت portmapper أو rpcbind للإعلان عن نقاط نهاية خدمتها للعملاء. يستخدم العملاء عفريت rpcbind لتحديد:

ما هو منفذ الشبكة الذي تستخدمه كل خدمة قائمة على RPC

ما هي بروتوكولات النقل التي تدعمها كل خدمة قائمة على RPC

يستخدم عفريت rpcbind رقم منفذ معروفًا (111) لمساعدة العملاء في العثور على نقطة نهاية الخدمة. على الرغم من أن NFS غالبًا ما يستخدم رقم منفذ قياسيًا (2049)، إلا أن الخدمات المساعدة مثل خدمة NLM يمكنها اختيار أي رقم منفذ غير مستخدم عشوائيًا.

تحظر إعدادات جدار الحماية الشائعة منفذ rpcbind المعروف. وفي غياب خدمة rpcbind، يثبّت مدير الخادم رقم المنفذ للخدمات المتعلقة بـ NFS حتى يتمكن جدار الحماية من السماح بالوصول إلى منافذ خدمة NFS محددة. يحدد مديرو العملاء بعد ذلك رقم المنفذ لخدمة mountd عبر الخيار mountport لأمر mount(8). قد يكون من الضروري أيضًا فرض استخدام TCP أو UDP إذا كان جدار الحماية يحظر أحد بروتوكولات النقل تلك.

قوائم التحكم في الوصول لـ NFS¶

يسمح سولاريس (Solaris) لعملاء إصدارة NFS رقم 3 بالوصول المباشر إلى قوائم التحكم في الوصول POSIX المخزنة في أنظمة ملفاته المحلية. يوفر بروتوكول النطاق الجانبي الاحتكاري هذا، المعروف باسم NFSACL، تحكمًا في الوصول أغنى من بتات الأنماط. يطبق لينكس هذا البروتوكول للتوافق مع تطبيق Solaris NFS. ومع ذلك، لم يصبح بروتوكول NFSACL جزءًا قياسيًا من مواصفات إصدارة NFS رقم 3.

توجب مواصفات إصدارة NFS رقم 4 إصدارة جديدة من قوائم التحكم في الوصول تكون أغنى دلاليًا من قوائم POSIX ACLs. قوائم التحكم في الوصول لإصدارة NFS رقم 4 ليست متوافقة تمامًا مع قوائم POSIX ACLs؛ وعلى هذا النحو، يلزم بعض الترجمة بينهما في بيئة تمزج بين POSIX ACLs وإصدارة NFS رقم 4.

الفصل بعد إعادة الوصل¶

بالنسبة لنقاط الوصل التي تستخدم إصدارتَي NFS رقم 2 أو 3، يعتمد الأمر الفرعي NFS umount على معرفة المجموعة الأصلية لخيارات الوصل المستخدمة لإجراء عملية MNT. تُخزن هذه الخيارات على القرص بواسطة الأمر الفرعي لوصل NFS، ويمكن محوها بواسطة إعادة الوصل.

لضمان عدم محو خيارات الوصل المحفوظة أثناء إعادة الوصل، حدد إما دليل الوصل المحلي، أو اسم مضيف الخادم ومسار التصدير، ولكن ليس كلاهما، أثناء إعادة الوصل. على سبيل المثال،

	mount -o remount,ro /mnt

يدمج خيار الوصل ro مع خيارات الوصل المحفوظة بالفعل على القرص لخادم NFS الموصول عند /mnt.