การกำหนดค่าสองแบบแก้ปัญหาเดียวกันและล้มเหลวในทิศทางตรงกันข้าม การเมานต์แชร์ตอนบูตทำให้ทุกบริการได้ระบบไฟล์ที่มีอยู่จริงหรือมีเหตุผลว่าทำไมการบูตจึงหยุดชะงัก การเมานต์อัตโนมัติเมื่อมีการเรียกใช้ทำให้เครื่องบูตเร็วและยกภาระการรอให้กับผู้ที่แตะเส้นทางเป็นคนแรก เบื้องหลัง VPN วิธีที่สองมักเป็นการแลกเปลี่ยนที่ดีกว่า และเหตุผลคืออุโมงค์บังคับลำดับที่ลำดับการบูตมองไม่เห็น

การเมานต์ตอนบูตเทียบกับการเมานต์อัตโนมัติ

การเมานต์ตอนบูตนั้นเข้าใจง่าย เป้าหมายของระบบไฟล์รอการเมานต์ บริการที่ประกาศการพึ่งพามันจะเริ่มหลังจากนั้น และถ้าเข้าถึงเซิร์ฟเวอร์ไม่ได้ เครื่องจะรอหรือล้มเหลวขึ้นอยู่กับตัวเลือก ทุกสิ่งปลายน้ำสืบทอดการตัดสินใจครั้งเดียวนั้น

การเมานต์อัตโนมัติกลับกัน เส้นทางมีอยู่ทันที การเมานต์จริงเกิดขึ้นเมื่อมีบางอย่างเปิดมัน และบริการที่เริ่มต้นเร็วจะไม่ติดขัดกับอุโมงค์ที่ยังไม่ขึ้น

การเปรียบเทียบลงเอยที่ว่าใครควรแบกความล่าช้า สถานีงานที่ต้องการแชร์ก่อนผู้ใช้จะทำงานได้น่าจะควรรอ แล็ปท็อปที่บูตในกระเป๋า หรือเซิร์ฟเวอร์ที่แชร์เป็นทางเลือก ไม่ควรรอ

ไม่มีตัวเลือกใดซ่อมเส้นทางที่หายไป ทั้งสองเพียงตัดสินว่าเมื่อใดจะสังเกตเห็นความล้มเหลว

บรรทัด fstab ทีละตัวเลือก

สมมติว่าอินสแตนซ์ไคลเอนต์ OpenVPN ที่มีอยู่คือ [email protected] เซิร์ฟเวอร์คือ files.corp.example และจุดเมานต์คือ /mnt/work แทนที่ทั้งสามด้วยค่าที่ได้รับอนุญาตจากไซต์ของคุณเอง บรรทัดที่ใช้งานได้หน้าตาแบบนี้:

files.corp.example:/export/work /mnt/work nfs _netdev,nofail,x-systemd.automount,[email protected],x-systemd.mount-timeout=30s 0 0

_netdev ทำเครื่องหมายการเมานต์ว่าต้องการเครือข่าย และไม่ได้ระบุอุโมงค์ใดเลย nofail ทำให้แชร์เป็นทางเลือกสำหรับเป้าหมายระบบไฟล์ปกติ x-systemd.automount สร้างตัวกระตุ้นเมื่อมีการเรียกใช้แทนการเมานต์ทันที

x-systemd.requires= คือส่วนที่ผูกความพยายามเมานต์กับยูนิต VPN และมันเป็นของการดําเนินการเมานต์ ไม่ใช่ตัวกระตุ้น การวางลําดับกว้างๆ บนยูนิตเมานต์อัตโนมัติเองคือวิธีที่ผู้คนสร้างวงจรซึ่ง systemd จะบ่นในภายหลังด้วยภาษาที่ไม่มีใครอ่านสองครั้ง

x-systemd.mount-timeout=30s จำกัดคำสั่งเมานต์เริ่มต้น มันไม่ได้จำกัดสิ่งใดที่เกิดขึ้นหลังจากนั้น และนี่คือความเข้าใจผิดที่พบบ่อยที่สุดเกี่ยวกับตัวเลือกนี้

สิ่งที่ «เริ่มแล้ว» ไม่ได้หมายถึง

ตรวจสอบว่า การเป็นแอ็กทิฟหมายถึงอะไร สำหรับยูนิต VPN ที่คุณระบุ บริการอุโมงค์สามารถรายงานตนเองว่าเริ่มแล้วก่อนที่เส้นทางไปยังเซิร์ฟเวอร์ไฟล์จะมีอยู่ หรือก่อนที่ชื่อส่วนตัวจะถูกแปลง และการเรียงลำดับหลังจากนั้นก็ไม่ได้ประโยชน์อะไร ช่องว่างนี้คือที่อยู่ของเกือบทุกความพยายามที่ล้มเหลว มันยังมองไม่เห็นเว้นแต่คุณจะดูเส้นทางและตัวแปลงชื่อแทนสถานะของยูนิต

ใช้สัญญาณความพร้อมของเจ้าของการเชื่อมต่อเองเป็นข้อกำหนดเบื้องต้นเพิ่มเติมในที่ที่มีอยู่ การนอนหลับแบบคงที่เป็นการเดาที่ได้ผลบนโต๊ะของคุณและล้มเหลวบนเครือข่ายที่ช้ากว่าหรือหลังการเชื่อมต่อใหม่

ตรวจสอบยูนิตที่สร้างขึ้นสำหรับเส้นทางในตัวอย่าง: mnt-work.automount และ mnt-work.mount หลังจากแก้ไข fstab ที่ผ่านการตรวจสอบแล้ว ให้โหลด systemd ใหม่และจัดการยูนิตเหล่านั้นโดยตรงแทนการเรียกคำสั่งเมานต์แบบเหมารวมที่ฝึกฝนรายการที่ไม่เกี่ยวข้อง

มีข้อควรระวังอีกข้อหนึ่งที่นี่ บริการที่แตะ /mnt/work ตอนเริ่มยังคงกระตุ้นการเมานต์และยังคงรอมัน ดังนั้นการทำเครื่องหมายแชร์เป็นทางเลือกไม่ได้ทำให้ทุกแอปพลิเคชันอดทน

หลังการเมานต์ ความล้มเหลวเป็นอีกแบบหนึ่ง

เมื่อ NFS ถูกเมานต์แล้ว พฤติกรรมการลองใหม่และการกู้คืนของระบบไฟล์จะเป็นตัวกำหนดว่าเหตุขัดข้องในภายหลังจะทำอะไรกับการอ่านหรือการเขียน หมดเวลาเมานต์ที่คุณตั้งไว้ไม่มีอิทธิพลต่อสิ่งนั้น

การเมานต์แบบซอฟต์ย่อการรอบางส่วนและเปลี่ยนความหมายของข้อผิดพลาด พร้อมผลต่อความสมบูรณ์ของข้อมูลที่มองข้ามได้ง่ายเมื่อเป้าหมายคือการบูตที่เร็วขึ้น การเลือกมันเพื่อแลกกับสองวินาทีของการเริ่มต้นไม่ค่อยเป็นการแลกเปลี่ยนที่ดี หากข้อกำหนดคือการดำเนินการที่มีขอบเขตระหว่างเหตุขัดข้องจริงๆ นั่นคือการตัดสินใจระดับแอปพลิเคชัน ไม่ใช่แฟล็ก fstab

ตัดสินใจว่าจะเกิดอะไรขึ้นกับโปรเซสที่กำลังเขียนอยู่เมื่ออุโมงค์ล่ม แล้วจดไว้ คำตอบนั้นมีประโยชน์กว่าสตริงตัวเลือกใดๆ

ทดสอบสี่สถานะ ไม่ใช่หนึ่ง

การบูตปกติเมื่ออุโมงค์พร้อมใช้งานเป็นกรณีง่ายและพิสูจน์แทบไม่ได้เลย มันยืนยันว่าสตริงเขียนถูกต้องและไม่มีอะไรมากกว่านั้น ทดสอบการเข้าถึงครั้งแรกโดยไม่มี VPN จากนั้นการกู้คืนเมื่อมันขึ้น จากนั้นเหตุขัดข้องที่ควบคุมได้หลังการเมานต์สำเร็จ

สี่สถานะ สี่การสังเกต และบันทึกจะอยู่ข้างรายการ fstab คนถัดไปจะสืบทอดพฤติกรรมแทนการกำหนดค่าที่ต้องย้อนรอยวิศวกรรม

บทความที่เกี่ยวข้อง