caminho tl; dr
Seu diagrama está essencialmente correto.
/dev/<device> arquivos
Acho que a maneira mais básica de começar a responder sua pergunta é com o que /dev/<device>são os arquivos. Digamos que você tenha um disco rígido. Esse disco rígido possui uma tabela de partições baseada em MBR e duas partições, uma ext4 formatada com alguns arquivos e a outra configurada para o LVM. Observe que esta resposta fala sobre a criação rápida de arquivos de dispositivos, o que implica que você está usando um kernel do Linux. As coisas são um pouco diferentes em outros escritórios.
Quando você conecta este disco rígido (ou quando o sistema o detecta no momento da inicialização), um arquivo de dispositivo será criado no /devdiretório - geralmente chamado /dev/sd*ou /dev/hd*( ou dependendo do controlador usado para conectar a unidade) - o * é um carta. Os bytes no arquivo do dispositivo são essencialmente mapeados linearmente para os bytes no disco físico: se você usar uma ferramenta para gravar no início do arquivo do dispositivo, esses dados também serão gravados no início físico do disco físico.
Agora, o sistema também entende tabelas de partição como MBRs e GPTs. Depois que o arquivo inicial do dispositivo for criado, ele será lido para determinar se ele possui uma tabela de partição. Caso isso aconteça, os arquivos do dispositivo que representam essas partições serão criados. Assim, assumindo que o arquivo de dispositivo original foi chamado /dev/sda, um arquivo de dispositivo chamado /dev/sda1será criado (representando a primeira partição ext4 formatada), assim como um /dev/sda2dispositivo (representando a segunda partição LVM). Eles são mapeados linearmente para suas respectivas partições da mesma maneira que toda a unidade - ou seja, se você usar uma ferramenta para (por exemplo) gravar no início /dev/sda2, os dados gravados serão fisicamente gravados no início da segunda partição , que na verdade é o meio do disco inteiro, porque é aí que a segunda partição é iniciada.
Blocos e setores
Este é um momento conveniente para falar sobre blocos e setores: estas são apenas medidas de espaço em um disco físico, nada mais (pelo menos se eu entendi corretamente). Um setor é uma região física em um disco rígido; normalmente é de 512 bytes - 4 KB em discos rígidos mais recentes. Um bloco também é uma unidade de medida, tem quase sempre 8 KB. Quando alguém fala sobre leitura e gravação de blocos, isso significa que, em vez de ler cada byte de dados individualmente, eles lêem e gravam dados em pedaços de 8 KB.
Sistemas de arquivos e inodes
Em seguida, sistemas de arquivos e inodes. Um sistema de arquivos é um conceito bastante simples: no início da região em que o sistema de arquivos reside (essa região geralmente é uma partição), há várias informações sobre o sistema de arquivos. Esse cabeçalho (também conhecido como superbloco, acredito) é usado primeiro para determinar qual driver do sistema de arquivos deve ser usado para ler o sistema de arquivos e, em seguida, é usado pelo driver do sistema de arquivos escolhido para ler os arquivos. Essa é uma simplificação, é claro, mas basicamente armazena duas coisas (que podem ou não ser armazenadas como duas estruturas de dados distintas no disco, dependendo do tipo fs): a árvore de diretórios e uma lista de inodes. A árvore de diretórios é o que você vê quando faz um lsoutree. A árvore de diretórios indica quais arquivos e diretórios são filhos de quais outros diretórios. O relacionamento arquivo / diretório pai-filho forma a árvore de diretórios UNIX como a conhecemos.
Mas a árvore de diretórios inclui apenas nomes. Esses nomes também são associados aos números de inode. Um número de inode contém informações como onde as partes de um arquivo são fisicamente armazenadas no disco. Um inode por si só é simplesmente "um arquivo" sem nome; um inode é associado a um nome através da árvore de diretórios. Veja também O que é um superbloco, inode, dentry e um arquivo?
Até agora, temos a seguinte explicação: /dev/sd*arquivos mapeados para discos rígidos, /dev/sd*#arquivos mapear para o número de partição #em /dev/sd*. Um sistema de arquivos é uma estrutura de dados em disco que controla uma árvore de diretórios; geralmente é mantido em uma partição ( /dev/sd*#). Um sistema de arquivos contém inodes; inodes são números que representam arquivos, juntamente com dados associados a esses arquivos (exceto pelo nome e posição na árvore de diretórios).
Vale a pena notar que os sistemas de arquivos geralmente controlam os dados em blocos. Geralmente, a árvore de diretórios e a lista de inodes são armazenadas em blocos, não em bytes, e os inodes apontam para blocos no disco, não bytes. (Isso pode causar problemas em que os arquivos geralmente gastam meio bloco de espaço, porque o sistema de arquivos alocou um bloco inteiro, mas não precisou usar esse bloco inteiro para a última parte do arquivo.)
O mapeador de dispositivos
A peça final do quebra-cabeça é um módulo muito importante no kernel do Linux, chamado mapeador de dispositivos (carregue-o com modprobe dm). O mapeador de dispositivos basicamente permite criar outro arquivo de dispositivo no /dev/mapperdiretório Esse arquivo de dispositivo é mapeado para outra fonte de dados, possivelmente sendo transformada no processo. O exemplo mais simples é ler uma parte de um arquivo.
Digamos que você tenha uma imagem de disco completo, completa com a tabela de partição. Você precisa ler os dados de uma das partições da imagem, mas não pode acessar apenas essa partição, pois é uma imagem de disco completo, em vez de uma imagem de partição única. A solução é descobrir onde está a imagem da sua partição e criar um novo arquivo de dispositivo mapeado para essa parte da imagem do disco. Aqui está um diagrama:
.-------------------.
| /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.
Outra maneira de pensar nisso é como um pipeline de transformação (esta é a metáfora mais precisa do que está acontecendo internamente no kernel). Imagine uma correia transportadora. Uma solicitação - uma leitura, uma gravação etc. - começa em uma extremidade da correia transportadora, em um arquivo de dispositivo criado com o mapeador de dispositivos. A solicitação viaja através da transformação do mapeador de dispositivo para o arquivo de origem. No exemplo acima, esse arquivo de origem é um arquivo regular diskimage.img,. Aqui está o diagrama:
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
Observe como, no diagrama, a lógica de transformação conectada ao mapeador de dispositivos possui poucas ferramentas +para manipular a solicitação de leitura à medida que ela se move na correia transportadora.
Agora, eu particularmente não sinto vontade de copiar esse diagrama e modificá-lo para o LVM, mas basicamente a parte da transformação pode ser qualquer coisa - não apenas mudando o intervalo de bytes para a frente. É assim que o LVM funciona: uma extensão física do LVM é a parte do LVM que fica no disco e monitora onde estão os dados. Pense nisso como o sistema de arquivos do LVM. Na metáfora da correia transportadora, uma extensão física é um dos arquivos de origem e a transformação é o LVM, mapeando uma solicitação em um volume lógico (que é o item mais à esquerda na correia transportadora) para os dados físicos no disco. Falando nisso...
Estou um pouco enferrujado com meus conceitos de LVM, mas o IIRC, um Grupo de Volume é essencialmente como um disco no LVM. Novamente, os níveis de IIRC, RAID etc. são gerenciados por grupo de volumes. Um volume lógico, então, é como uma partição, e os volumes lógicos são o que realmente têm arquivos de dispositivo que os representam. Você coloca sistemas de arquivos e outras coisas em volumes lógicos.
O legal do mapeador de dispositivos é que a lógica criada com ele pode ser inserida arbitrariamente na pilha de dados - tudo o que você precisa fazer é alterar o nome do dispositivo que está lendo. É assim que as partições criptografadas funcionam ( não os esquemas de criptografia que funcionam no nível do arquivo - eles usam o FUSE), e é assim que o LVM funciona. Não consigo pensar em nenhum outro exemplo no momento, mas confie em mim, o mapeador de dispositivos é muito foda.
Endereçamento de bloco lógico
Eu nunca ouvi falar disso, então não posso oferecer nenhuma informação sobre isso. Espero que alguém apareça e edite esta resposta.
