ацій read і write з локальними файлами, які отримують зсув з об'єкта "відкритий файл". p> Протокол без збереження станів спрощує відновлення після краху системи. Якщо відмовляє клієнтська система, ніякого відновлення не потрібно, оскільки сервер не підтримує ніякої стійкої інформації про клієнта. Якщо клієнт перезавантажився, він може перемонтувати файлові системи і запустити програми, які звертаються до віддалених файлів. Серверу не потрібно ні знати, ні турбуватися про відмову клієнта. p> Якщо відмовляє сервер, то клієнт побачить, що на свої запити він не отримує відповіді. Тоді він продовжує повторно посилати запити до тих пір, поки сервер НЕ перезавантажиться. (Це справедливо тільки у випадку жорсткого монтування (яке виконується за замовчуванням). При м'якому монтуванні клієнт через деякий час припиняє посилку запитів і повертає додатком повідомлення про помилку). З цього моменту часу сервер почне отримувати запити і може їх обробляти, оскільки запити не залежать ні від якої більш ранньої інформації про стан. Коли нарешті сервер відповість на запити, клієнт перестане їх повторно посилати. У клієнта немає жодних коштів визначити, чи дійсно сервер відмовив і був перезавантажений, або просто повільно виконує операції. p> Протоколи з збереженням стану вимагають реалізації складних механізмів відновлення після відмови. Сервер повинен виявляти відмови клієнта і ліквідувати всі стани, пов'язані з цим клієнтом. Якщо відмовляє і перезавантажується сервер, він повинен повідомити клієнтів так, щоб вони могли заново створити свій стан на сервері. p> Головна проблема роботи без збереження стану полягає в тому, що сервер повинен зафіксувати всі зміни в стабільній пам'яті до посилки відповіді на запит. Це означає, що не тільки дані файлу, а й всі метадані, такі як індексні дескриптори або непрямі блоки повинні бути скинуті на диск до повернення результатів. В іншому випадку сервер може втратити дані, про які клієнт впевнений, що вони успішно записалися на диск. (Відмова системи може призвести до втрати даних навіть у локальній файловій системі, але в таких випадках користувачі знають про відмову і про можливість втратити дані). Робота без збереження стану пов'язана також з іншими недоліками. Вона вимагає окремого протоколу (NLM) для забезпечення блокування файлів. Крім того, щоб вирішити проблеми продуктивності операцій синхронного запису більшість клієнтів кешують дані та метадані локально. Але це суперечить гарантіям протоколу про дотримання узгодженого стану. < Загальні відомості про роботу і навантаженні NFS
Принаймні на системах Sun чисті сервери NFS являють собою найбільш прості для конфігурування широкомасштабні сервери, головним чином тому, що вони працюють з одним і тим же кодом операційної системи (мається тільки одна реалізація сервера NFS, яку можна знайти на Sun, оскільки вона являє собою пов'язаний з операційною системою продукт). Більше того, самі по собі сервіси NFS відносно прості, так як ...
