yol tl; dr
Diyagramınız aslında doğrudur.
/dev/<device> Dosyalar
Bence sorunuzu cevaplamaya başlamanın en temel yolu /dev/<device>dosyaların ne olduğudur. Sabit diskiniz olduğunu varsayalım. Bu sabit diskin MBR tabanlı bir bölüm tablosu vardır ve biri üzerinde bazı dosyalarla biçimlendirilmiş ext4, diğerinde LVM için ayarlanmış iki bölüm vardır. Bu yanıtın, Linux çekirdeği kullandığınızı ima eden anında aygıt dosyası oluşturma hakkında konuşulduğunu unutmayın. Diğer Unices'te işler biraz farklı .
Bu sabit diski taktığınızda (veya sistem önyükleme sırasında algıladığında) /devdizinde bir aygıt dosyası oluşturulur - genellikle ya /dev/sd*da denir /dev/hd*(sürücüyü bağlamak için hangi denetleyicinin kullanıldığına bağlı olarak) - * bir mektup. Aygıt dosyasındaki baytlar esasen fiziksel diskteki baytlarla doğrusal olarak eşlenir: aygıt dosyasının başlangıcına yazmak için bir araç kullanırsanız, bu veriler fiziksel diskin fiziksel başlangıcına da yazılır.
Sistem artık MBR'ler ve GPT'ler gibi bölüm tablolarını da anlıyor. İlk cihaz dosyası oluşturulduktan sonra, bir bölüm tablosu olup olmadığını belirlemek için okunur. Varsa, bu bölümleri temsil eden aygıt dosyaları oluşturulur. Orijinal aygıt dosyasının çağrıldığı varsayılarak, adlandırılan /dev/sdabir aygıt dosyası /dev/sda1(birinci, ext4 biçimli bölümü /dev/sda2temsil eder) ve bir aygıt (ikinci LVM bölümünü temsil eder) oluşturulur. Bunlar, tüm sürücüyle aynı şekilde ilgili bölümlerine doğrusal olarak eşlenir - yani, başında yazmak için (örneğin) bir araç kullanırsanız /dev/sda2, yazılan veriler fiziksel olarak ikinci bölümün başına yazılır aslında ortası çünkü ikinci bölüm burada başlar.
Bloklar ve sektörler
Bu, bloklar ve sektörler hakkında konuşmak için uygun bir zamandır: bunlar sadece fiziksel bir diskteki alan ölçümleri, daha fazlası değil (en azından doğru anlarsam). Sektör, sabit diskteki fiziksel bir bölgedir; genellikle 512 bayt - daha yeni sabit disklerde 4 KB. Bir blok da bir ölçü birimidir, neredeyse her zaman 8 KB'dir. Birisi blokları okuma ve yazma hakkında konuştuğunda, bu, her bir veri baytını ayrı ayrı okumak yerine, 8 KB'lik parçalar halinde veri okuduğu ve yazdığı anlamına gelir.
Dosya sistemleri ve inode'lar
Sıradaki dosya sistemleri ve inode'lar. Bir dosya sistemi oldukça basit bir kavramdır: dosya sisteminin bulunduğu bölgenin başında (bu bölge genellikle bir bölümdür), dosya sisteminde bir sürü bilgi vardır. Bu üstbilgi (süper blok olarak da bilinir) ilk olarak dosya sistemini okumak için hangi dosya sistemi sürücüsünün kullanılması gerektiğini belirlemek için kullanılır ve daha sonra dosyaları okumak için seçilen dosya sistemi sürücüsü tarafından kullanılır. Bu bir basitleştirmedir, ancak temel olarak iki şeyi saklar (fs türüne bağlı olarak diskte iki ayrı veri yapısı olarak saklanabilir veya saklanamaz): dizin ağacı ve bir inode listesi. Dizin ağacı, birls veya birtree. Dizin ağacı, hangi dosyaların ve dizinlerin diğer dizinlerin alt öğeleri olduğunu belirtir. Dosya / dizin üst-alt ilişkisi, bildiğimiz gibi UNIX dizin ağacını oluşturur.
Ancak dizin ağacı yalnızca adları içerir. Bu adlar ek olarak inode numaraları ile ilişkilidir. Bir inode numarası, bir dosyanın parçalarının fiziksel olarak diskte nerede saklandığı gibi bilgiler içerir. Bir inode tek başına adı olmayan bir "dosya" dır; bir inode, dizin ağacı üzerinden bir adla ilişkilendirilir. Ayrıca bkz. Superblock, Inode, Dentry ve Dosya nedir?
Şimdiye kadar aşağıdaki açıklamaya sahibiz: /dev/sd*dosyalar sabit sürücülere, /dev/sd*#dosyalar bölüm numarasına #eşleniyor /dev/sd*. Bir dosya sistemi, disk üzerinde bir dizin ağacının kaydını tutan bir veri yapısıdır; genellikle bir bölüm ( /dev/sd*#) içinde tutulur . Bir dosya sistemi inode içerir; inodes, dosyaları temsil eden numaralarla birlikte bu dosyalarla ilişkili verilerdir (dizin ağacındaki adları ve konumları hariç).
Dosya sistemlerinin genellikle bloklar halinde verileri izlediğini belirtmek gerekir. Genellikle, dizin ağacı ve inode listesi bayt olarak değil bloklar halinde depolanır ve inotlar bayt değil, disk üzerindeki blokları gösterir. (Bu, dosyaların tipik olarak yarım blok alanı boşa harcadığı durumlarda sorunlara neden olabilir, çünkü dosya sistemi tüm bir bloğu ayırdı, ancak dosyanın tüm kısmı için bu bloğun tamamını kullanması gerekmedi.)
Cihaz eşleyici
Bulmacanın son parçası, Linux çekirdeğinde cihaz eşleştiricisi olarak adlandırılan çok önemli bir modüldür (yükleyin modprobe dm). Aygıt eşleyici temel olarak /dev/mapperdizinde başka bir aygıt dosyası oluşturmanıza olanak tanır . Bu cihaz dosyası daha sonra başka bir veri kaynağına eşlenir ve muhtemelen işlemde dönüştürülür. Bunun en basit örneği, dosyanın bir bölümünü okumaktır.
Bölüm tablosu ile birlikte tam disk görüntünüz olduğunu varsayalım. Verileri görüntüdeki bölümlerden birinden okumalısınız, ancak tek bölümlü bir görüntü yerine tam diskli bir görüntü olduğu için yalnızca bu bölüme ulaşamazsınız. Çözüm, bölümünüzün görüntüde nerede olduğunu bulmak ve sonra disk görüntüsünün o bölümü ile yeni bir aygıt dosyası eşleme oluşturmaktır. İşte bir diyagram:
.-------------------.
| /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.
Bunu düşünmenin başka bir yolu da bir dönüşüm boru hattı gibidir (bu, çekirdekte dahili olarak olanlar için daha doğru bir metafordur). Bir taşıma bandı düşünün. Konveyör bandının bir ucunda, aygıt eşleyici ile oluşturulan bir aygıt dosyasında bir istek - okuma, yazma vb. - başlar. İstek daha sonra aygıt eşleyici dönüşümü yoluyla kaynak dosyaya gider. Yukarıdaki örnekte, bu kaynak dosya normal bir dosyadır diskimage.img. İşte şema:
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
Şemada, cihaz eşleyici ile bağlanan dönüşüm mantığının +, taşıma bandında hareket ederken okuma isteğini manipüle etmek için küçük araçlara sahip olduğuna dikkat edin.
Şimdi, bu diyagramı kopyalamak ve LVM için değiştirmek gibi bir şey hissetmiyorum, ancak temel olarak, dönüşüm kısmı herhangi bir şey olabilir - sadece bayt aralığını ileriye kaydırmak değil. LVM şu şekilde çalışır: LVM Fiziksel Uzantı, LVM'nin disk üzerinde oturan ve verilerin nerede olduğunu izleyen kısmıdır. Bunu LVM dosya sistemi gibi düşünün. Konveyör bandı metaforunda, bir Fiziksel Uzantı kaynak dosyalardan biridir ve dönüşüm LVM'dir, Mantıksal Hacimdeki (konveyör bandındaki en soldaki öğe) bir talebi diskteki fiziksel verilerle eşler. Konuşan ...
LVM konseptlerim için biraz paslıyım, ancak bir Volume Group olan IIRC, LVM'deki bir disk gibi. Yine, Grup Grubu başına IIRC, RAID seviyeleri vb. Yönetilir. Mantıksal Birim, tıpkı bir bölüm gibidir ve Mantıksal Birimler aslında onları temsil eden aygıt dosyalarına sahiptir. Mantıksal Birimlere dosya sistemleri ve şeyler koydunuz.
Cihaz eşleyici ile ilgili en güzel şey, onunla oluşturulmuş mantığın veri yığınına keyfi olarak eklenebilmesidir - tek yapmanız gereken okuduğunuz cihazın adını değiştirmek. Şifreli bölümler bu şekilde çalışır ( dosya düzeyinde çalışan şifreleme şemaları değil - FUSE kullanır) ve LVM böyle çalışır. Şu anda başka bir örnek düşünemiyorum ama bana güven, cihaz haritacısı oldukça kötü.
Mantıksal Blok Adresleme
Bunu hiç duymadım, bu yüzden bu konuda herhangi bir bilgi sunamıyorum. Umarım birisi gelip bu cevabı düzenler.