Saya agak malu untuk menanyakan pertanyaan ini tetapi saya ingin melihat diagram yang menunjukkan bagaimana hal-hal berikut ini terkait. Akan lebih baik jika diagram juga menyertakan transformasi apa pun yang diperlukan untuk memetakan di antara berbagai lapisan juga.
Seperti yang saya pahami, saya yakin mereka terkait dengan cara berikut, tetapi saya tidak yakin bahwa pemahaman saya 100% akurat.
.-----------------.
| inode |
'-----------------'
|
.-----------------.
| EXT4 |
'-----------------'
|
.---------------------.
| logical volume (LV) | --- part of LVM
'---------------------'
|
.-------------------.
| volume group (VG) | --- part of LVM
'-------------------'
|
.---------------.
| /dev/<device> |
'---------------'
|
.--------------------------------.
| Logical Block Addressing (LBA) |
'--------------------------------'
|
.-----------------.
| blocks/sectors |
'-----------------'
|
HDD
_.-----._
.- -.
|-_ _-|
| ~-----~ |
| |
`._ _.'
"-----"
Referensi
- Menemukan sektor hard drive yang menempati file
- Mengidentifikasi file yang terkait dengan sektor disk yang tidak dapat dibaca
- HOWTO blok buruk untuk smartmontools
- C5170 Catatan kuliah — Representasi Internal File – Sistem File Unix
- Pengalamatan blok logis
- Tata Letak Disk Ext4
Jawaban yang Diterima:
cara tl;dr
Diagram Anda pada dasarnya benar.
/dev/<device> file
Saya pikir cara paling dasar untuk mulai menjawab pertanyaan Anda adalah dengan apa /dev/<device> file adalah. Katakanlah Anda memiliki hard disk. Hard disk ini memiliki tabel partisi berbasis MBR, dan memiliki dua partisi, satu diformat ext4 dengan beberapa file di dalamnya, dan yang lainnya diatur untuk LVM. Perhatikan bahwa jawaban ini berbicara tentang pembuatan file perangkat on-the-fly, yang menyiratkan bahwa Anda menggunakan kernel Linux. Hal-hal sedikit berbeda di Unis lainnya.
Saat Anda mencolokkan hard disk ini (atau saat sistem mendeteksinya saat boot), file perangkat akan dibuat di /dev direktori – biasanya disebut /dev/sd* atau /dev/hd* (tergantung pada pengontrol apa yang digunakan untuk menghubungkan drive) – * adalah huruf. Byte pada file perangkat pada dasarnya dipetakan secara linier ke byte pada disk fisik:jika Anda menggunakan alat untuk menulis ke awal file perangkat, data tersebut 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 disebut /dev/sda , file perangkat bernama /dev/sda1 akan dibuat (mewakili partisi pertama yang diformat ext4), serta /dev/sda2 perangkat (mewakili partisi LVM kedua). Ini dipetakan secara linier 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 ditulis secara fisik ke awal partisi kedua, yang sebenarnya adalah tengah seluruh disk, karena di situlah partisi kedua dimulai.
Blok dan sektor
Ini adalah waktu yang tepat 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. Sebuah blok juga merupakan satuan pengukuran, hampir selalu 8 KB. Ketika seseorang berbicara tentang membaca dan menulis blok, itu hanya berarti bahwa alih-alih membaca setiap byte data satu per satu, mereka membaca dan menulis data dalam potongan 8 KB.
Sistem file dan inode
Selanjutnya, filesystem dan inode. Sistem file adalah konsep yang cukup sederhana:di awal wilayah tempat sistem file berada (wilayah ini biasanya merupakan partisi), ada banyak informasi tentang sistem file. Header ini (juga disebut sebagai superblok, saya percaya) pertama kali digunakan untuk menentukan driver sistem file mana yang harus digunakan untuk membaca sistem file, dan kemudian digunakan oleh driver sistem file 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 saat melakukan ls atau tree . Pohon direktori menyatakan file dan direktori mana yang merupakan turunan dari direktori lain. Hubungan induk-anak file/direktori membentuk pohon direktori UNIX seperti yang kita kenal.
Tetapi pohon direktori hanya menyertakan nama. Nama-nama itu juga terkait dengan nomor inode. Nomor inode berisi informasi seperti di mana potongan-potongan file disimpan secara fisik di disk. Sebuah inode dengan sendirinya hanyalah "sebuah file" tanpa nama; sebuah inode dikaitkan dengan nama melalui pohon direktori. Lihat juga Apa itu Superblock, Inode, Dentry, dan File?
Sejauh ini, kami memiliki penjelasan berikut:/dev/sd* file dipetakan ke hard drive, /dev/sd*# file dipetakan ke nomor partisi # di /dev/sd* . Sistem file adalah struktur data pada disk yang melacak pohon direktori; biasanya 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.)
Pemeta perangkat
Bagian terakhir dari teka-teki ini adalah modul yang sangat penting di kernel Linux yang disebut device mapper (muat dengan modprobe dm ). Pemeta perangkat pada dasarnya memungkinkan Anda membuat file perangkat lain di /dev/mapper direktori. File perangkat itu kemudian dipetakan ke sumber data lain, mungkin diubah dalam prosesnya. Contoh paling sederhana adalah membaca sebagian file.
Katakanlah Anda memiliki gambar full-disk, lengkap dengan tabel partisi. Anda perlu membaca data dari salah satu partisi pada gambar, tetapi Anda tidak bisa hanya partisi itu, karena ini adalah gambar disk penuh, bukan gambar partisi tunggal. Solusinya adalah menemukan di mana gambar partisi Anda berada, dan kemudian membuat pemetaan file perangkat baru ke bagian gambar disk tersebut. Berikut diagramnya:
.-------------------.
| /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 sebuah 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 device mapper ke file sumber. Pada 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 dihubungkan dengan device mapper memiliki sedikit alat (+ s) untuk memanipulasi permintaan baca saat bergerak di ban berjalan.
Sekarang, saya tidak terlalu ingin menyalin diagram itu dan memodifikasinya untuk LVM, tetapi pada dasarnya, bagian transformasi dapat berupa apa saja – tidak hanya menggeser rentang byte ke depan. Beginilah cara kerja LVM:Luas Fisik LVM adalah bagian dari LVM yang berada di disk dan melacak lokasi data. Anggap saja seperti sistem file LVM. Dalam metafora sabuk konveyor, Luas Fisik adalah salah satu file sumber, dan transformasinya adalah LVM yang melakukan tugasnya, memetakan permintaan pada Volume Logis (yang merupakan item paling kiri pada sabuk konveyor) ke data fisik pada disk. Omong-omong…
Saya sedikit berkarat pada konsep LVM saya, tetapi IIRC, Grup Volume pada dasarnya seperti disk di LVM. Sekali lagi, IIRC, level RAID, dll. dikelola per Grup Volume. Sebuah Volume Logis, kemudian, seperti sebuah partisi, dan Volume Logis adalah apa yang sebenarnya memiliki file perangkat yang mewakili mereka. Anda meletakkan sistem file dan lainnya di Volume Logis.
Hal yang keren tentang device mapper adalah bahwa logika yang dibangun dengannya dapat dimasukkan secara sewenang-wenang ke dalam tumpukan data – yang harus Anda lakukan adalah mengubah nama perangkat yang sedang Anda baca. Beginilah cara kerja partisi terenkripsi (bukan skema enkripsi yang bekerja pada tingkat file – yang menggunakan FUSE), dan beginilah cara kerja LVM. Saya tidak bisa memikirkan contoh lain saat ini, tapi percayalah, device mappernya cukup keren.
Pengalamatan Blok Logis
Saya belum pernah mendengar tentang ini, jadi saya tidak dapat memberikan informasi apa pun tentangnya. Mudah-mudahan seseorang akan datang dan mengedit jawaban ini.