cara tl; dr
Diagram Anda pada dasarnya benar.
/dev/<device> file
Saya pikir cara paling dasar untuk mulai menjawab pertanyaan Anda adalah dengan /dev/<device>file apa itu. Katakanlah Anda memiliki hard disk. Hard disk ini memiliki tabel partisi berbasis MBR, dan memiliki dua partisi, satu ext4 diformat dengan beberapa file di dalamnya, dan yang lainnya diatur untuk LVM. Perhatikan bahwa jawaban ini berbicara tentang pembuatan file perangkat sambil jalan, yang menyiratkan bahwa Anda menggunakan kernel Linux. Hal- hal sedikit berbeda pada Unix lainnya.
Ketika Anda mencolokkan hard disk ini (atau ketika sistem mendeteksi saat boot) file perangkat akan dibuat di /devdirektori - umumnya disebut salah satu /dev/sd*atau /dev/hd*(tergantung pada apa controller yang digunakan untuk menghubungkan drive) - the * adalah surat. Bytes pada file perangkat pada dasarnya dipetakan secara linier ke byte pada disk fisik: jika Anda menggunakan alat untuk menulis ke awal file perangkat, data itu juga akan ditulis ke awal fisik disk fisik.
Sekarang, sistem juga memahami tabel partisi seperti MBR dan GPT. Setelah file perangkat awal dibuat, itu akan dibaca untuk menentukan apakah itu memiliki tabel partisi. Jika ya, file perangkat yang mewakili partisi ini akan dibuat. Jadi dengan asumsi bahwa file perangkat asli dipanggil /dev/sda, file perangkat yang disebut /dev/sda1akan dibuat (mewakili partisi berformat ext4 pertama), serta /dev/sda2perangkat (mewakili partisi LVM kedua). Ini dipetakan secara linear ke partisi masing-masing dengan cara yang sama seperti seluruh drive - yaitu, jika Anda menggunakan alat untuk (misalnya) menulis ke awal /dev/sda2, data yang ditulis akan secara fisik ditulis ke awal partisi kedua , yang sebenarnya tengah seluruh disk, karena di situlah partisi kedua dimulai.
Blok dan sektor
Ini adalah waktu yang nyaman untuk berbicara tentang blok dan sektor: ini hanya pengukuran ruang pada disk fisik, tidak lebih (setidaknya jika saya mengerti dengan benar). Sektor adalah wilayah fisik pada hard drive; biasanya 512 byte - 4 KB pada hard drive yang lebih baru. Blok juga merupakan unit pengukuran, hampir selalu 8 KB. Ketika seseorang berbicara tentang membaca dan menulis blok, itu berarti bahwa alih-alih membaca setiap byte data secara individual, mereka membaca dan menulis data dalam potongan 8 KB.
Sistem file dan inode
Selanjutnya, sistem file dan inode. Filesystem adalah konsep yang cukup sederhana: di awal wilayah di mana filesystem berada (wilayah ini biasanya merupakan partisi), ada banyak informasi tentang filesystem. Header ini (juga disebut sebagai superblock, saya percaya) pertama kali digunakan untuk menentukan driver filesystem mana yang harus digunakan untuk membaca filesystem, dan kemudian digunakan oleh driver filesystem yang dipilih untuk membaca file. Ini adalah penyederhanaan, tentu saja, tetapi pada dasarnya menyimpan dua hal (yang mungkin atau mungkin tidak disimpan sebagai dua struktur data yang berbeda pada disk, tergantung pada jenis fs): pohon direktori dan daftar inode. Pohon direktori adalah apa yang Anda lihat ketika Anda melakukan lsatautree. Pohon direktori menyatakan file dan direktori mana yang merupakan anak dari direktori lain. Hubungan file / direktori orangtua-anak membentuk pohon direktori UNIX seperti yang kita kenal.
Tetapi pohon direktori hanya mencakup nama. Nama-nama itu juga dikaitkan dengan nomor inode. Nomor inode berisi informasi seperti di mana potongan-potongan file secara fisik disimpan pada disk. Inode dengan sendirinya hanyalah "file" tanpa nama; inode dikaitkan dengan nama melalui pohon direktori. Lihat juga Apa itu Superblock, Inode, Dentry, dan File?
Sejauh ini, kita memiliki penjelasan sebagai berikut: /dev/sd*file peta ke hard drive, /dev/sd*#file peta ke nomor partisi #pada /dev/sd*. Filesystem adalah struktur data pada disk yang melacak pohon direktori; umumnya disimpan dalam partisi ( /dev/sd*#). Sistem file berisi inode; inode adalah angka yang mewakili file, bersama dengan data yang terkait dengan file tersebut (kecuali untuk nama dan posisinya di pohon direktori).
Perlu dicatat bahwa sistem file umumnya melacak data dalam blok. Biasanya, pohon direktori dan daftar inode disimpan dalam blok, bukan dalam byte, dan inode menunjuk ke blok pada disk, bukan byte. (Ini dapat menyebabkan masalah di mana file biasanya menghabiskan setengah blok ruang, karena sistem file mengalokasikan seluruh blok tetapi tidak perlu menggunakan seluruh blok itu untuk bagian terakhir file.)
Mapper perangkat
Bagian terakhir dari teka-teki adalah modul yang sangat penting dalam kernel Linux yang disebut device mapper (memuatnya dengan modprobe dm). Mapper perangkat pada dasarnya memungkinkan Anda membuat file perangkat lain di /dev/mapperdirektori. File perangkat itu kemudian dipetakan ke sumber data lain, mungkin ditransformasikan dalam proses. Contoh paling sederhana adalah membaca sebagian file.
Katakanlah Anda memiliki gambar disk penuh, lengkap dengan tabel partisi. Anda perlu membaca data dari salah satu partisi dalam gambar, tetapi Anda tidak bisa hanya partisi itu, karena itu adalah gambar disk penuh, bukan gambar partisi tunggal. Solusinya adalah menemukan di mana dalam gambar partisi Anda, dan kemudian membuat pemetaan file perangkat baru ke bagian gambar disk. Berikut diagram:
.-------------------.
| /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.
Cara lain untuk memikirkannya adalah seperti pipa transformasi (ini adalah metafora yang lebih akurat untuk apa yang terjadi secara internal di kernel). Bayangkan ban berjalan. Permintaan - baca, tulis, dll. - dimulai di salah satu ujung ban berjalan, pada file perangkat yang dibuat dengan mapper perangkat. Permintaan kemudian berjalan melalui transformasi mapper perangkat ke file sumber. Dalam contoh di atas, file sumber ini adalah file biasa diskimage.img,. Berikut diagramnya:
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
Perhatikan bagaimana dalam diagram, logika transformasi yang telah dikaitkan dengan mapper perangkat memiliki sedikit alat +untuk memanipulasi permintaan baca saat bergerak melalui sabuk konveyor.
Sekarang, saya tidak merasa ingin menyalin diagram itu dan memodifikasinya untuk LVM, tetapi pada dasarnya, bagian transformasi bisa apa saja - tidak hanya menggeser rentang byte ke depan. Ini adalah cara kerja LVM: Extent Fisik LVM adalah bagian dari LVM yang duduk di disk dan melacak di mana data berada. Anggap saja seperti sistem file LVM. Dalam metafor sabuk konveyor, Extent Fisik adalah salah satu file sumber, dan transformasi adalah LVM melakukan hal itu, memetakan permintaan pada Volume Logika (yang merupakan item paling kiri pada sabuk konveyor) ke data fisik pada disk. Ngomong-ngomong soal...
Saya sedikit berkarat pada konsep LVM saya, tetapi IIRC, Volume Group pada dasarnya seperti disk di LVM. Sekali lagi, IIRC, level RAID, dll. Dikelola per Grup Volume. Volume Logical, kemudian, sama seperti partisi, dan Volume Logis adalah yang sebenarnya mewakili file perangkat. Anda meletakkan filesystem dan hal-hal lain di Volume Logis.
Yang paling keren tentang device mapper adalah bahwa logika yang dibangun dengannya dapat dimasukkan secara sewenang-wenang ke dalam tumpukan data - yang harus Anda lakukan hanyalah mengubah nama perangkat yang sedang Anda baca. Ini adalah cara kerja partisi terenkripsi ( bukan skema enkripsi yang bekerja di tingkat file - yang menggunakan FUSE), dan ini adalah cara kerja LVM. Saya tidak dapat memikirkan contoh lain saat ini, tetapi percayalah, mapper perangkat ini sangat buruk.
Mengatasi Blok Logis
Saya belum pernah mendengar ini, jadi saya tidak bisa menawarkan informasi apa pun tentang itu. Semoga seseorang akan datang dan mengedit jawaban ini.