เหตุใดการเมานท์จึงเกิดขึ้นกับไดเรกทอรีที่มีอยู่

ไดเรกทอรีที่มีอยู่เป็นสิ่งจำเป็นเป็นจุดเชื่อมต่อ

$ ls
$ sudo mount /dev/sdb2 ./datadisk
mount: mount point ./datadisk does not exist
$ mkdir datadisk
$ sudo mount /dev/sdb2 ./datadisk
$

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

เหตุใดจึงไม่mountเกิดขึ้นในไดเรกทอรีที่สร้างขึ้นใหม่ นี่คือวิธีที่ระบบปฏิบัติการกราฟิกแสดงสื่อบันทึกข้อมูลแบบถอดได้ มันจะชัดเจนหากติดตั้งไดเรกทอรี (มีอยู่) หรือไม่ได้ติดตั้ง (ไม่มีอยู่) ฉันค่อนข้างมั่นใจว่ามีเหตุผลที่ดี แต่ฉันยังไม่สามารถค้นพบได้

นี่เป็นกรณีของรายละเอียดการใช้งานที่รั่วไหลออกมา

ในระบบ UNIX ทุกไดเร็กทอรีประกอบด้วยรายการชื่อที่แม็พกับหมายเลขไอโหนด ไอโหนดเก็บเมตาดาต้าซึ่งบอกระบบว่าเป็นไฟล์ไดเรกทอรีอุปกรณ์พิเศษชื่อไปป์ ฯลฯ หากเป็นไฟล์หรือไดเรกทอรีมันยังบอกระบบว่าจะหาไฟล์หรือเนื้อหาของไดเร็กตอรี่ในดิสก์ได้ที่ใด inodes ส่วนใหญ่เป็นไฟล์หรือไดเรกทอรี -iตัวเลือกในการlsจะแสดงหมายเลขไอโหนด

การติดตั้งระบบไฟล์จะใช้ไดเร็กทอรี inode และตั้งค่าสถานะบนสำเนาในหน่วยความจำของเคอร์เนลเพื่อพูดว่า "จริง ๆ แล้วเมื่อค้นหาเนื้อหาของไดเรกทอรีนี้ให้ดูที่ระบบไฟล์อื่นแทน" (ดูสไลด์ 10 ของงานนำเสนอนี้ ) สิ่งนี้ค่อนข้างง่ายเนื่องจากกำลังเปลี่ยนรายการข้อมูลเดียว

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

หากคุณต้องการจุดเชื่อมต่อที่สร้างขึ้นแบบไดนามิกautomountระบบสามารถทำได้ พิเศษ filesystems ไม่ใช่ดิสก์ยังสามารถสร้างไดเรกทอรีที่จะเช่นproc, sys, devfsและอื่น ๆ

แก้ไข: ดูคำตอบสำหรับสิ่งที่เกิดขึ้นเมื่อคุณ 'เมานต์' โฟลเดอร์ที่มีเนื้อหาอยู่

หากmount(2) ต้องการสร้างไดเรกทอรีใหม่ให้เป็นจุดเชื่อมต่อคุณจะไม่สามารถเมานต์สิ่งใด ๆ ภายใต้ระบบไฟล์แบบอ่านอย่างเดียว นั่นจะเป็นใบ้ดังนั้นเราสามารถแยกแยะออกได้

หากการเมานต์สร้างทางเลือกไดเรกทอรีใหม่ให้เป็นจุดเมานท์นั่นจะแปลก มันไม่เหมือนการเมานท์ / unmount เกิดขึ้นตลอดเวลาดังนั้นการวางตรรกะพิเศษในเคอร์เนลเพื่อทำสองขั้นตอนเหล่านี้ด้วยการเรียกระบบครั้งเดียวจะไม่เป็นการเร่งความเร็วที่สำคัญ เพียงแค่ปล่อยให้มันขึ้นอยู่กับพื้นที่ของผู้ใช้เพื่อทำการmkdir(2)โทรออกระบบหากต้องการ คำตอบของ Dmitry ชี้ให้เห็นว่าการmount(2)ทำทั้งสองอย่างนั้นจะไม่ทำให้เกิดปรมาณู และคุณต้องการอาร์กิวเมนต์พิเศษที่จะmount(2)มีธงโหมดชอบopen(2)ใช้เวลาสำหรับO_CREAT, O_EXCLฯลฯ มันก็จะโง่เมื่อเทียบกับการปล่อยให้ผู้ใช้พื้นที่ทำมัน

หรือบางทีคุณถูกถามว่ามีmount(8)(โปรแกรมดั้งเดิมที่mount(2)เรียกใช้ระบบ) ทำเช่นนี้? นั่นอาจเป็นไปได้ แต่ก็มีประโยชน์อย่างสมบูรณ์แบบmkdir(1)สำหรับงานและการออกแบบของ Unix นั้นเป็นเครื่องมือขนาดเล็กที่ดีที่สามารถรวมเข้าด้วยกัน หากคุณต้องการเครื่องมือที่ทำทั้งสองอย่างมันเป็นเรื่องง่ายที่จะเขียนเชลล์สคริปเพื่อสร้างเครื่องมือนั้นจากสองเครื่องมือที่ง่ายกว่า (หรือตามที่ muru แสดงความคิดเห็นudisksctlได้ทำเช่นนี้แล้วดังนั้นคุณไม่จำเป็นต้องเขียน) นอกจากนี้ Linux ทั่วไปmount(8)จาก util-linux สนับสนุนการmount -o x-mount.mkdir[=mode]ใช้มันเป็นx-ไวยากรณ์สำหรับตัวเลือกสำหรับ userspace มากกว่าตัวเลือกที่จะส่งผ่านไปยังระบบไฟล์

ตอนนี้คำถามที่น่าสนใจมากขึ้น: ทำไมต้องมีไดเรกทอรีในระบบไฟล์หลักเลย?

เช่นเดียวกับคำตอบของ pjc50 ชี้ให้เห็น (ไม่มีส่วนเกี่ยวข้องแม้เขาจะมีชื่อย่อของฉัน!) readdir()มีจุดเชื่อมต่อแสดงในรายการไดเรกทอรีแล้วจะต้องมีการตรวจสอบเป็นพิเศษในทุก

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

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

1. mount สร้างจุดเมานต์สำเร็จแล้ว
2. mount พยายามเมานต์ระบบไฟล์ใหม่ไปยังไดเร็กทอรีนั้น แต่ล้มเหลว
3. mount พยายามลบจุดเมานท์ แต่ล้มเหลว

mountระบบจะจบลงด้วยผลข้างเคียงของล้มเหลว

นี่คืออีกหนึ่ง:

1. umount ประสบความสำเร็จในการยกเลิกการต่อเชื่อมระบบไฟล์
2. umount พยายามลบจุดเมานท์ แต่ล้มเหลว

ตอนนี้ควรumountกลับสู่ความสำเร็จหรือล้มเหลวหรือไม่

อีกกรณีหนึ่งที่สามารถเกิดขึ้นได้:

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

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

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

ฉันก็สงสัยเช่นกัน

เสื้อคลุมเรียบง่ายเช่น:

#!/bin/sh
eval "mkdir -p \"\$$#\"" 
/bin/mount "$@"  

บันทึกเป็นสคริปต์ที่เรียกใช้งานได้ซึ่งมีชื่อmountอยู่ในไดเรกทอรีที่เขียนทับ/binใน PATH ของคุณควรดูแลสิ่งนี้หากมันรบกวนคุณมากเกินไป

(ก่อนที่จะเรียกใช้mountไบนารีจริงมันจะสร้างไดเรกทอรีที่ตั้งชื่อตามอาร์กิวเมนต์ล่าสุดmountหากไม่มีไดเรกทอรีดังกล่าวอยู่แล้ว)

อีกทางเลือกหนึ่งถ้าคุณไม่ต้องการให้ invocations ของmountwrapper สร้างไดเรคทอรีล้มเหลวคุณสามารถทำได้:

#!/bin/sh
set -e
eval "lastArg=\"\$$#\""
test -d "$lastArg" || { mkdir "$lastArg"; madeDir=1; }
/bin/mount "$@"  ||  {  test -z "$madeDir" || rmdir "$lastArg"; }