OTOthoTools

NFS एंट्री बिल्डर

विश्वसनीय माउंट एंट्री बनाएँ
परिणामfstab
10.20.0.15:/srv/shared  /mnt/shared  nfs  rw,hard,_netdev,nofail,x-systemd.automount,nfsvers=4.2,timeo=600,retrans=2  0  0
  • hard विकल्प सर्वर रुकावटों के दौरान चुपचाप डेटा भ्रष्टाचार रोकता है।
  • _netdev और systemd automount बूट पर होने वाली माउंट विफलताएँ रोकते हैं।

परिचय

NFS एंट्री बिल्डर एक NFS शेयर के लिए fstab पंक्ति बनाता है जिसमें माउंट को मज़बूत बनाने वाले विकल्प होते हैं: soft के बजाय hard, _netdev ताकि बूट नेटवर्क का इंतज़ार करे, nofail ताकि गायब शेयर बूट न रोके, और x-systemd.automount माँग पर माउंटिंग के लिए।

hard माउंट अनुरोध तब तक दोहराते हैं जब तक सर्वर जवाब न दे; soft माउंट ऐसी त्रुटियाँ लौटा सकते हैं जिन्हें एप्लिकेशन वास्तविक I/O विफलता समझ लेते हैं, इसलिए अधिकांश कार्यभारों के लिए hard ही अनुशंसित डिफ़ॉल्ट है।

उद्देश्य

  • सर्वर, export, माउंट पॉइंट और NFS संस्करण से सही, पूर्ण fstab पंक्ति बनाना।
  • उत्पादन-उन्मुख डिफ़ॉल्ट लागू करना: hard, _netdev, nofail, automount, timeo और retrans।
  • NFSv3 चुनने पर चेतावनी देना, क्योंकि इसे rpcbind और अतिरिक्त फ़ायरवॉल नियम चाहिए।

इनपुट

  • NFS सर्वर होस्टनाम या IP।
  • सर्वर पर export पथ (उदाहरण: /srv/shared)।
  • स्थानीय माउंट पॉइंट (उदाहरण: /mnt/shared)।
  • NFS संस्करण: 4.2, 4.1, 4 या 3।

यह कैसे काम करता है

उपकरण fstab के छह फ़ील्ड जोड़ता है: डिवाइस के रूप में server:export, माउंट पॉइंट, फ़ाइलसिस्टम प्रकार nfs, विकल्प सूची, dump के लिए 0 और fsck pass के लिए 0।

विकल्प सूची इनपुट से बनती है: rw, hard, _netdev, nofail, x-systemd.automount, nfsvers=<संस्करण>, timeo=600 और retrans=2। timeo और retrans नियंत्रित करते हैं कि क्लाइंट कितनी देर प्रतीक्षा करे और हारने से पहले कितनी बार पुनः प्रयास करे।

यदि NFSv3 चुना जाता है, तो चेतावनी जुड़ती है क्योंकि NFSv3 rpcbind पर निर्भर है और सर्वर फ़ायरवॉल में अतिरिक्त पोर्ट खोलता है; जब सर्वर समर्थन करे तो NFSv4 बेहतर है।

परीक्षण योग्य उदाहरण

आज़माएँ — विश्लेषण आपके ब्राउज़र में स्थानीय रूप से चलता है।

उदाहरण

सर्वर: 10.20.0.15
Export: /srv/shared
माउंट: /mnt/shared
संस्करण: 4.2

अपेक्षित आउटपुट

10.20.0.15:/srv/shared  /mnt/shared  nfs  rw,hard,_netdev,nofail,x-systemd.automount,nfsvers=4.2,timeo=600,retrans=2  0  0
परिणाम: कोई गंभीर समस्या नहीं मिली।

आउटपुट पढ़ना

  • बनी पंक्ति को /etc/fstab में ज्यों-का-त्यों जोड़ें और फिर sudo mount -a से माउंट करें।
  • अच्छे निष्कर्ष पुष्टि करते हैं कि hard और _netdev मौजूद हैं — ये दो विकल्प NFS की दो सबसे आम विफलता शैलियों को रोकते हैं।
  • यदि NFSv3 की चेतावनी दिखे, तो स्वीकारने से पहले जाँचें कि सर्वर NFSv4 समर्थन करता है या नहीं।

जोखिम

  • hard माउंट कभी हारते नहीं: यदि सर्वर हमेशा के लिए गायब हो जाए, तो प्रक्रियाएँ तब तक लटक सकती हैं जब तक सर्वर लौटे या माउंट न हटे।
  • Automount माउंट को पहले एक्सेस तक टालता है, जिससे उन सेवाओं का व्यवहार बदलता है जो बूट पर पथ की अपेक्षा करती हैं।
  • बिना परीक्षण के बनी पंक्ति को /etc/fstab में चिपकाना उत्पादन सर्वर का बूट तोड़ सकता है।

सीमाएँ

  • उपकरण कनेक्टिविटी, exports या प्रमाणीकरण (जैसे NFSv4 Kerberos) का परीक्षण नहीं करता।
  • विकल्प एक समझदार आधार हैं, सार्वभौमिक सर्वोत्तम अभ्यास नहीं — उच्च-विलंबता या विशेष कार्यभारों को अलग timeo/retrans मान चाहिए।
  • यह सर्वर पक्ष के लिए /etc/exports प्रविष्टियाँ नहीं बनाता।

आधिकारिक संदर्भ

FAQ

hard की जगह soft क्यों नहीं?

soft माउंट टाइमआउट के बाद त्रुटि लौटा सकता है भले ही सर्वर केवल धीमा हो, और एप्लिकेशन अक्सर उसे वास्तविक I/O विफलता मान लेते हैं। hard माउंट प्रयास जारी रखते हैं, जो अधिकांश मामलों में डेटा अखंडता के लिए सुरक्षित है।

nofail क्या करता है?

nofail सिस्टम को बताता है कि भले ही यह माउंट विफल हो, बूट जारी रखे — इमरजेंसी मोड में जाने के बजाय। वैकल्पिक शेयरों के लिए यह आवश्यक है।

x-systemd.automount क्या है?

यह systemd को शेयर को बूट पर नहीं बल्कि पहले एक्सेस पर माउंट करने देता है, ताकि धीमा या अनुपलब्ध सर्वर बूट में देरी न करे। माउंट पॉइंट तुरंत मौजूद रहता है; वास्तविक माउंट आलसी रूप से होता है।