วิธี tl; dr
แผนภาพของคุณถูกต้องเป็นหลัก
/dev/<device> ไฟล์
ฉันคิดว่าวิธีพื้นฐานที่สุดในการเริ่มตอบคำถามของคุณคือ/dev/<device>ไฟล์อะไร สมมติว่าคุณมีฮาร์ดดิสก์ ฮาร์ดดิสก์นี้มีตารางพาร์ติชันที่ใช้ MBR และมีสองพาร์ติชันหนึ่งในรูปแบบ ext4 ที่มีไฟล์อยู่ในนั้นและอีกไฟล์หนึ่งตั้งค่าไว้สำหรับ LVM โปรดทราบว่าคำตอบนี้พูดถึงการสร้างไฟล์อุปกรณ์แบบทันทีซึ่งแสดงว่าคุณใช้เคอร์เนล Linux สิ่งต่าง ๆ เล็กน้อยใน Unices อื่น ๆ
เมื่อคุณเสียบฮาร์ดดิสก์นี้ (หรือเมื่อระบบตรวจพบได้ตอนบูท) ไฟล์อุปกรณ์จะถูกสร้างขึ้นใน/devไดเรกทอรี - โดยทั่วไปเรียกว่าอย่างใดอย่างหนึ่ง/dev/sd*หรือ/dev/hd*(ขึ้นอยู่กับคอนโทรลเลอร์ที่ใช้ในการเชื่อมต่อไดรฟ์) - * คือ จดหมาย ไบต์บนไฟล์อุปกรณ์จะถูกแมปเป็นเส้นตรงเป็นไบต์บนฟิสิคัลดิสก์: หากคุณใช้เครื่องมือเพื่อเขียนไปยังจุดเริ่มต้นของไฟล์อุปกรณ์ข้อมูลนั้นจะถูกเขียนไปยังฟิสิคัลเริ่มต้นของฟิสิคัลดิสก์
ตอนนี้ระบบยังเข้าใจตารางพาร์ติชันเช่น MBRs และ GPT เมื่อไฟล์อุปกรณ์เริ่มต้นถูกสร้างขึ้นมันจะถูกอ่านเพื่อตรวจสอบว่ามันมีตารางพาร์ทิชัน หากเป็นเช่นนั้นไฟล์อุปกรณ์ที่แสดงพาร์ติชันเหล่านี้จะถูกสร้างขึ้น ดังนั้นสมมติว่าไฟล์อุปกรณ์ดั้งเดิมถูกเรียก/dev/sdaใช้ไฟล์อุปกรณ์ที่เรียก/dev/sda1จะถูกสร้างขึ้น (แทนพาร์ติชันที่จัดรูปแบบ ext4 แรก) เช่นเดียวกับ/dev/sda2อุปกรณ์ (แสดงพาร์ติชัน LVM ที่สอง) สิ่งเหล่านี้จะถูกแมปเชิงเส้นตรงกับพาร์ติชั่นตามลำดับเช่นเดียวกับไดรฟ์ทั้งหมด - นั่นคือถ้าคุณใช้เครื่องมือในการเขียน (ตัวอย่าง) ไปยังจุดเริ่มต้น/dev/sda2ข้อมูลที่เขียนจะถูกเขียนทางกายภาพไปยังจุดเริ่มต้นของพาร์ติชันที่สอง ซึ่งจริงๆแล้วอยู่ตรงกลาง ของทั้งดิสก์เพราะนั่นคือจุดที่พาร์ติชั่นที่สองเริ่มต้นขึ้น
บล็อกและภาค
นี่เป็นเวลาที่สะดวกในการพูดคุยเกี่ยวกับบล็อกและเซกเตอร์: นี่เป็นเพียงการวัดพื้นที่บนดิสก์จริงไม่มีอะไรเพิ่มเติม (อย่างน้อยถ้าฉันเข้าใจถูกต้อง) ภาคคือพื้นที่ทางกายภาพในฮาร์ดไดรฟ์ โดยทั่วไปแล้ว 512 ไบต์ - 4 KB สำหรับฮาร์ดไดรฟ์รุ่นใหม่ บล็อกยังเป็นหน่วยวัดซึ่งเกือบจะเป็น 8 KB เมื่อมีคนพูดถึงการอ่านและการเขียนบล็อกนั่นหมายความว่าแทนที่จะอ่านแต่ละไบต์ของข้อมูลทีละรายการพวกเขาอ่านและเขียนข้อมูลเป็นหน่วย 8 KB
ระบบไฟล์และ inodes
ระบบไฟล์และ inodes ระบบไฟล์เป็นแนวคิดที่ค่อนข้างง่าย: ที่จุดเริ่มต้นของภูมิภาคซึ่งระบบไฟล์ตั้งอยู่ (ภูมิภาคนี้มักจะเป็นพาร์ติชัน) มีข้อมูลมากมายเกี่ยวกับระบบไฟล์ ส่วนหัวนี้ (เรียกอีกอย่างว่า superblock ผมเชื่อว่า) เป็นครั้งแรกที่ใช้ในการตรวจสอบไดรเวอร์ระบบไฟล์ที่ควรใช้ในการอ่านระบบไฟล์และจากนั้นมันจะถูกใช้โดยไดรเวอร์ระบบไฟล์ที่เลือกเพื่ออ่านไฟล์ แน่นอนว่าเป็นการทำให้เข้าใจง่าย แต่โดยทั่วไปแล้วจะเก็บสองสิ่ง (ซึ่งอาจหรืออาจจะไม่ถูกจัดเก็บเป็นโครงสร้างข้อมูลสองแบบที่แตกต่างกันบนดิสก์ขึ้นอยู่กับชนิด fs): แผนผังไดเร็กทอรีและรายการ inodes ต้นไม้ไดเรกทอรีเป็นสิ่งที่คุณเห็นเมื่อคุณทำlsหรือtree. แผนผังต้นไม้ระบุว่าไฟล์และไดเรกทอรีใดเป็นลูกของไดเรกทอรีอื่น ความสัมพันธ์ของไฟล์ / ไดเรกทอรี parent-child สร้างแผนผังไดเร็กทอรี UNIX ตามที่เรารู้
แต่แผนผังไดเร็กทอรีมีชื่อเท่านั้น ชื่อเหล่านั้นจะเชื่อมโยงเพิ่มเติมกับหมายเลข inode หมายเลขไอโหนดมีข้อมูลเหมือนที่ชิ้นส่วนของไฟล์ถูกเก็บไว้ในดิสก์ inode ด้วยตัวมันเองเป็นเพียง "ไฟล์" ที่ไม่มีชื่อ inode เชื่อมโยงกับชื่อผ่านแผนผังทรี ดูเพิ่มเติมSuperblock, Inode, Dentry และไฟล์คืออะไร?
จนถึงขณะนี้เรามีคำอธิบายต่อไปนี้: /dev/sd*ไฟล์แมปไปยังฮาร์ดไดรฟ์, /dev/sd*#ไฟล์แผนที่ไปยังหมายเลขพาร์ทิชันบน# /dev/sd*ระบบไฟล์เป็นโครงสร้างข้อมูลบนดิสก์ที่คอยติดตามทรีไดเรกทอรี โดยทั่วไปจะถูกเก็บไว้ในพาร์ติชัน ( /dev/sd*#) ระบบไฟล์มีไอโหนด inodes คือตัวเลขที่แสดงถึงไฟล์พร้อมกับข้อมูลที่เชื่อมโยงกับไฟล์เหล่านั้น (ยกเว้นชื่อและตำแหน่งในแผนผังไดเรกทอรี)
เป็นที่น่าสังเกตว่าระบบไฟล์โดยทั่วไปจะติดตามข้อมูลในบล็อก โดยปกติทรีไดเรกทอรีและรายการ inode จะถูกเก็บไว้ในบล็อกไม่ใช่ในไบต์และ inodes ชี้ไปที่บล็อกบนดิสก์ไม่ใช่ไบต์ (ซึ่งอาจทำให้เกิดปัญหาที่โดยทั่วไปไฟล์เสียพื้นที่ครึ่งบล็อกเนื่องจากระบบไฟล์จัดสรรทั้งบล็อก แต่ไม่จำเป็นต้องใช้ทั้งบล็อกนั้นสำหรับส่วนสุดท้ายของไฟล์)
ผู้ทำแผนที่อุปกรณ์
ชิ้นส่วนสุดท้ายของจิ๊กซอว์เป็นโมดูลที่สำคัญมากในเคอร์เนล Linux ที่เรียกว่าmapper อุปกรณ์ (โหลดด้วยmodprobe dm) ผู้ทำแผนที่อุปกรณ์โดยทั่วไปช่วยให้คุณสร้างไฟล์อุปกรณ์อื่นใน/dev/mapperไดเรกทอรี ไฟล์อุปกรณ์นั้นจะถูกแมปไปยังแหล่งข้อมูลอื่นซึ่งอาจมีการแปลงในกระบวนการ ตัวอย่างที่ง่ายที่สุดคือการอ่านบางส่วนของไฟล์
สมมติว่าคุณมีอิมเมจดิสก์เต็มพร้อมด้วยตารางพาร์ติชัน คุณจะต้องอ่านข้อมูลปิดหนึ่งในพาร์ทิชันในภาพ แต่คุณไม่สามารถไปเพียงแค่พาร์ติชันที่เพราะมันเป็นรูปแบบดิสก์แทนของภาพที่พาร์ติชันเดียว วิธีการแก้ไขคือการหาตำแหน่งที่อิมเมจพาร์ติชันของคุณอยู่จากนั้นสร้างการแมปไฟล์อุปกรณ์ใหม่ไปยังส่วนนั้นของอิมเมจดิสก์ นี่คือแผนภาพ:
.-------------------.
| /dev/mapper/foo | <- This is the device file created with the device mapper
.___________________.
\ /
\ /
\ / <- This is a small section of the image being mapped to
\ / the new device file
\ /
\ /
.------------------.
| diskimage.img | <- This is the full-disk image. It's a regular file.
.__________________. Notice how the mapping goes to _part_ of the file.
อีกวิธีที่จะคิดว่ามันเป็นเหมือนท่อส่งการเปลี่ยนแปลง (นี่เป็นคำเปรียบเทียบที่แม่นยำยิ่งขึ้นสำหรับสิ่งที่เกิดขึ้นภายในเคอร์เนล) ลองนึกภาพสายพาน คำร้องขอ - การอ่านการเขียน ฯลฯ - เริ่มต้นที่ปลายด้านหนึ่งของสายพานลำเลียงบนไฟล์อุปกรณ์ที่สร้างด้วยตัวแม็พอุปกรณ์ คำร้องขอเดินทางผ่านการแปลงอุปกรณ์ตัวแม็ปไปยังไฟล์ต้นฉบับ ในตัวอย่างข้างต้น, diskimage.imgแฟ้มแหล่งที่มานี้เป็นไฟล์ปกติ นี่คือแผนภาพ:
Read operation goes onto
device mapper conveyor belt
read() The device mapper transforms the read The modified read request finally
\ request by moving the requested region reaches the source file, and the data
\ Beginning of conveyor belt to read forward by some number of bytes. is retrieved from the filesystem.
\
\ .-------------------. .--------------------------. .------------------------.
\ | /dev/mapper/foo | | Transformation logic | | /path/to/diskimage.img |
\ .___________________. .___+_____+_____+_____+____. .________________________.
\-->
---------------------------------------------------------------------------------------------------------------
o o o o o o o o o o o
โปรดสังเกตว่าในแผนภาพตรรกะการแปลงรูปที่เชื่อมต่อกับอุปกรณ์ทำแผนที่มีเครื่องมือเล็ก ๆ น้อย ๆ+เพื่อจัดการกับคำร้องขอการอ่านขณะที่เคลื่อนย้ายโดยบนสายพานลำเลียง
ตอนนี้ฉันไม่รู้สึกเป็นพิเศษที่จะคัดลอกแผนภาพนั้นและแก้ไขมันสำหรับ LVM แต่โดยทั่วไปแล้วส่วนการแปลงสามารถเป็นอะไรก็ได้ - ไม่เพียงแค่เลื่อนช่วงไบต์ไปข้างหน้า นี่คือวิธีการทำงานของ LVM: LVM Physical Extent เป็นส่วนหนึ่งของ LVM ที่อยู่บนดิสก์และติดตามว่าข้อมูลอยู่ที่ไหน คิดเหมือนระบบไฟล์ของ LVM ในอุปมาของสายพานลำเลียง Physical Extent เป็นหนึ่งในไฟล์ต้นฉบับและการแปลงคือ LVM ทำสิ่งนั้นทำแผนที่คำร้องขอบน Logical Volume (ซึ่งเป็นรายการซ้ายสุดของสายพานลำเลียง) กับข้อมูลทางกายภาพบนดิสก์ พูดถึงสิ่งที่ ...
ฉันมีความคิดฟุ้งซ่านเล็กน้อยเกี่ยวกับแนวคิด LVM ของฉัน แต่ IIRC กลุ่มวอลุ่มเป็นเหมือนดิสก์ใน LVM อีกครั้ง IIRC ระดับ RAID ฯลฯ ได้รับการจัดการต่อกลุ่มวอลุ่ม โลจิคัลวอลุ่มจึงเหมือนกับพาร์ติชันและโลจิคัลวอลุ่มเป็นสิ่งที่มีไฟล์อุปกรณ์แสดงอยู่ คุณวางระบบไฟล์และข้อมูลต่าง ๆ ลงใน Logical Volumes
สิ่งที่ยอดเยี่ยมเกี่ยวกับตัวทำแผนที่อุปกรณ์คือตรรกะที่สร้างขึ้นด้วยมันสามารถแทรกลงในสแต็กข้อมูลโดยพลการ - สิ่งที่คุณต้องทำคือเปลี่ยนชื่ออุปกรณ์ที่คุณกำลังอ่าน นี่เป็นวิธีที่พาร์ติชันที่เข้ารหัสทำงานได้ ( ไม่ใช่รูปแบบการเข้ารหัสที่ทำงานในระดับไฟล์ - ใช้กับ FUSE) และนี่เป็นวิธีที่ LVM ทำงาน ฉันไม่สามารถนึกถึงตัวอย่างอื่น ๆ ได้ในขณะนี้ แต่เชื่อในตัวฉันเองผู้ทำแผนที่อุปกรณ์คือคนเลวทีเดียว
การจัดการบล็อกแบบลอจิคัล
ฉันไม่เคยได้ยินเรื่องนี้ดังนั้นฉันจึงไม่สามารถให้ข้อมูลใด ๆ กับมันได้ หวังว่าจะมีใครบางคนเข้ามาและแก้ไขคำตอบนี้