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


80

ตอนนี้/tmpมีไฟล์ชั่วคราวอยู่ในนั้น เมื่อฉันติดตั้งฮาร์ดไดรฟ์ ( /dev/sdc1) ที่ด้านบนของ/tmpฉันจะเห็นไฟล์ในฮาร์ดไดรฟ์ จะเกิดอะไรขึ้นกับเนื้อหาจริงของ/tmpเมื่อฮาร์ดไดรฟ์ของฉันติดตั้งอยู่ เป็นไปได้หรือไม่ที่จะทำการดำเนินงาน r / w กับเนื้อหาจริงของ/tmpในขณะที่ติดตั้งฮาร์ดไดรฟ์

python@lanix / $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       286G   43G  229G  16% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            3.8G  4.0K  3.8G   1% /dev
tmpfs           766M  1.4M  765M   1% /run
none            5.0M     0  5.0M   0% /run/lock
none            3.8G   38M  3.8G   1% /run/shm
none            100M   24K  100M   1% /run/user
/dev/sdb1       7.5G  2.7G  4.9G  35% /mnt
/dev/sdc1       932G  242G  691G  26% /tmp

คำตอบ:


117

จะเกิดอะไรขึ้นกับเนื้อหาจริงของ / tmp เมื่อติดตั้งฮาร์ดไดรฟ์ของฉัน

ไม่มีอะไรมากสวย มันถูกซ่อนไว้จากมุมมองไม่สามารถเข้าถึงได้ผ่านทางระบบไฟล์ปกติ

เป็นไปได้หรือไม่ที่จะทำการดำเนินงาน r / w กับเนื้อหาจริงของ / tmp ในขณะที่ติดตั้งฮาร์ดไดรฟ์

ใช่. กระบวนการที่มีการจัดการไฟล์ที่เปิดอยู่ภายใน "ต้นฉบับ" ของคุณ/tmpจะยังคงสามารถใช้งานได้ นอกจากนี้คุณยังสามารถสร้าง "ปรากฏขึ้นอีก" ที่อื่นโดยผูกติดตั้ง/ที่อื่น

# mount -o bind / /somewhere/else
# ls /somewhere/else/tmp  

นี่คือการทดลองเล็กน้อยที่คุณสามารถเรียกใช้เพื่อรับความรู้สึกที่ดีขึ้น (ฉันหวัง) สำหรับสิ่งที่เกิดขึ้น

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

ฉันสร้างผู้ใช้ที่เรียกใช้meบนเครื่องของฉันและสร้างไดเรกทอรีสุ่มในบ้านของเขาด้วยไฟล์:

me@home $ pwd
/home/me/tmp
me@home $ echo hello > some_file
me@home $ ls  
some_file
me@home $ cat some_file 
hello

ณ จุดนี้ไม่มีอะไรผิดปกติ - เป็นเพียงไดเรกทอรีธรรมดาที่มีไฟล์ธรรมดา ฉันเปิดเซสชันนั้นไว้อย่างที่มันเป็นcwdอยู่ภายในไดเรกทอรีทดสอบนั้น

/home/me/tmpเป็นรากผมสร้างระบบแฟ้มขนาดเล็กและติดมันมากกว่า

root@home # dd if=/dev/zero of=./fs bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.00467318 s, 2.2 GB/s

root@home # mkfs -t ext2 ./fs 
mke2fs 1.42.12 (29-Aug-2014)
[... snip ...]
Writing superblocks and filesystem accounting information: done

root@home # mount ./fs /home/me/tmp

จากนั้นฉันเปิดเทอร์มินัลใหม่meแล้วดู:

me@home #2 $ cd tmp
me@home #2 $ ls
lost+found
me@home #2 $ cat some_file
cat: some_file: No such file or directory
me@home #2 $ echo bye bye > some_file
-su: some_file: Permission denied

ดังนั้นไฟล์ที่เราสร้างนั้นไม่ชัดเจน lost+foundไดเรกทอรีที่บ่งบอกถึงรากของระบบแฟ้มต่อ และฉันก็สูญเสียสิทธิ์ในการเขียนดังนั้นจึงไม่ใช่ไดเรกทอรีดั้งเดิม

กลับไปที่meเซสชั่นแรกลองมาดูกันว่ามันจะเห็นโลก:

me@home $ echo something else > other_file

ไม่มีปัญหาในการเขียน

me@home $ cat some_file other_file 
hello
something else

ไฟล์ต้นฉบับยังคงอยู่ที่นั่นไฟล์ใหม่ที่สร้างขึ้นโดยไม่มีปัญหา

ฮะ? เกิดอะไรขึ้น?

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

เซสชั่นที่สองเข้าสู่ไดเรกทอรีหลังจากที่วางถูกวางลง ดังนั้นจึงเห็นระบบไฟล์ใหม่ที่ว่างเปล่า และระบบดูแลระบบ borked สิทธิ์ดังนั้นจึงไม่สามารถใช้พื้นที่ที่ร้องขอ ... ช่วยแก้ไข

root@home # chown me:users /home/me/tmp
me@home #2 $ echo bye bye > some_file
me@home #2 $ ls 
lost+found  some_file
me@home #2 $ cat some_file 
bye bye

เซสชั่น 1 สามารถหลบหนีจากใต้พรมได้หรือไม่? (มันเริ่มจะเหม็นอับ)

แน่นอน! หากเซสชั่น 1 เลื่อนแบ็คทรีของระบบไฟล์ออกจากเมานท์มันจะสูญเสียที่จับไปด้านในและจะตามติดเหมือนคนอื่น ๆ

me@home $ cd
me@home $ pwd
/home/me
me@home $ cd tmp
me@home $ cat some_file other_file
bye bye
cat: other_file: No such file or directory

มุมมองเดียวกับเซสชั่น # 2 เรากลับมาเป็นปกติ

แต่คุณจะรู้ได้อย่างไรว่าไฟล์ไม่หายไป? ไม่มีใครมองอีกต่อไป!

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

me@home $ mkdir ~/bind
root@home # mount -o bind /home/me /home/me/bind

(ใช่คุณสามารถผูกระบบแฟ้ม "ในตัวเอง" เคล็ดลับเด็ดใช่มั้ย?)

me@home $ ls bind/tmp
other_file  some_file
me@home $ cat bind/tmp/*
something else
hello

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


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

แม้ว่าหนึ่งหมายเหตุ: การติดตั้งเหนือ/tmpหรือ/var(หรือไดเรกทอรีใด ๆ ของ Core OS) ไม่ใช่ความคิดที่ดีเมื่อกระบวนการบู๊ตเสร็จสิ้น แอปพลิเคชั่นจำนวนมากออกจากสถานะในไดเรกทอรีเหล่านั้นและอาจสับสนอย่างมากหากคุณเล่นเกมที่อยู่รอบตัว


4
นี่เป็นคำตอบที่ยอดเยี่ยม - คุณก้าวข้ามสิ่งที่ฉันขอจากคุณ ความคิดในการผูกภูเขาก็เจ๋งเหมือนกัน! ขอบคุณสำหรับคำตอบโดยละเอียด ไชโย
ผู้ใช้

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

2
@ DanSheppard นั่นเป็นเหตุผลหนึ่งที่ฉันชอบจุดเมานท์ของฉันตั้ง chmod 000 นอกจากนี้ทำไม systemd จึงไม่สามารถบูตได้หากการติดตั้งที่สำคัญล้มเหลว
Zan Lynx

คุณอาจจะยัง -bind ติด/home/meบน/home/meแทนโฟลเดอร์ "ผูก"? คือวางพรมอีกอันไว้บนพรม หรือคุณจะต้องถอนติดตั้งfsก่อน?
jiggunjer

@ jiggunjer ดูเหมือนว่าunionตัวเลือกสามารถช่วยได้
hliu
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.