De tempos em tempos, com o objetivo de mudar para o sistema nervoso central, entrevistarei várias empresas de grande porte, principalmente São Petersburgo e Moscou, para o cargo de DevOps. Notei que em muitas empresas (em muitas boas empresas, por exemplo, Yandex), eles fazem duas perguntas semelhantes:
- o que é inode;
- por que razões é possível obter um erro ao gravar no disco (ou por exemplo: por que o espaço em disco pode acabar, uma essência).
Como costuma acontecer, eu tinha certeza de que conhecia bem esse tópico, mas assim que comecei a explicar, as lacunas de conhecimento se tornaram aparentes. Para sistematizar meu conhecimento, preencher as lacunas e não mais desonrar, enquanto escrevo este artigo, ele ainda pode ser útil.
Começarei "de baixo", ou seja, do disco rígido (unidades flash, SSDs e outras coisas modernas, descartamos, por exemplo, qualquer unidade antiga de 20 ou 80 gigabytes, porque o tamanho do bloco é de 512 bytes).
O disco rígido não sabe como endereçar seu espaço por byte, pois é dividido em blocos. A numeração do bloco começa com 0. (isso é chamado LBA, detalhes aqui:
wikipedia.org/wiki/LBA
Como você pode ver na figura, designei os blocos LBA como o nível do disco rígido. A propósito, você pode ver qual o tamanho do bloco que seu disco possui:
root@ubuntu:/home/serp
O nível acima marca a partição, uma para todo o disco (novamente, por simplicidade). Na maioria das vezes, dois tipos de marcação de partição são usados: msdos e gpt. Assim, o msdos é um formato antigo que suporta discos de até 2 TB, gpt é um novo formato que pode endereçar até 1 zettabyte de blocos de 512 bytes. No nosso caso, temos uma seção do tipo msdos, como pode ser visto na figura, a seção nesse caso começa com o bloco n ° 1, enquanto a seção zero é usada para MBR.
Na primeira seção, criei o sistema de arquivos ext2, por padrão, o tamanho do bloco é 4096 bytes, o que também é mostrado na figura. Você pode ver o tamanho do bloco do sistema de arquivos assim:
root@ubuntu:/home/serp
O parâmetro que precisamos é "Tamanho do bloco".
Agora, o mais interessante é como ler o arquivo / home / serp / testfile? Um arquivo consiste em um ou mais blocos do sistema de arquivos no qual seus dados são armazenados. Conhecendo o nome do arquivo, como encontrá-lo? Quais blocos para ler?
É aqui que os inodes são úteis. O sistema de arquivos ext2fs possui uma "tabela" que contém informações sobre todos os inodes. O número de inodes no caso do ext2fs é definido ao criar o sistema de arquivos. Observamos os números necessários no parâmetro "Inode count" da saída tune2fs, ou seja, nós temos 65536 partes. O inode contém as informações que precisamos: uma lista de blocos do sistema de arquivos para o arquivo que você está procurando. Como encontrar o número do inode para o arquivo especificado?
A correspondência do nome e do número do inode está contida no diretório, e o diretório em ext2fs é um arquivo de um tipo especial, ou seja, também possui seu próprio número de inode. Para quebrar esse círculo vicioso, um número de inode "fixo" "2" foi atribuído ao diretório raiz. Examinamos o conteúdo do número do inode 2:
root@ubuntu:/
Como você pode ver, o diretório que precisamos está contido no bloco com o número 579. Nele, encontraremos o número do nó para a pasta inicial e assim por diante, até que no diretório serp vejamos o número do nó para o arquivo solicitado. Se de repente alguém quiser verificar se o número está correto e se houver a informação certa, não é difícil. Nós fazemos:
root@ubuntu:/
Na saída, você pode ler os nomes dos arquivos no diretório
Então, cheguei à pergunta principal: "por que razões pode haver um erro de gravação"?
Naturalmente, isso acontecerá se não houver blocos livres no sistema de arquivos. O que pode ser feito neste caso? Além do óbvio "excluir algo desnecessário", deve-se lembrar que nos sistemas de arquivos ext2,3 e 4 existe algo como "contagem de blocos reservados". Se você olhar a lista acima, temos os blocos "13094". Estes são blocos graváveis apenas para o usuário root. mas se você precisar resolver rapidamente o problema, como uma solução temporária pode ser disponibilizada para todos, resultando em um pouco de espaço livre:
root@ubuntu:/mnt
I.e. por padrão, você não possui 5% do espaço em disco disponível para gravação e, dado o volume de discos modernos, pode ser centenas de gigabytes.
O que mais poderia ser? Uma situação é possível quando há blocos livres, mas os nós terminaram. Isso geralmente acontece se você tiver vários arquivos no sistema de arquivos menores que o tamanho do bloco do sistema de arquivos. Considerando que 1 inode é gasto em 1 arquivo ou diretório, e no total os temos (para este sistema de arquivos) 65536 - a situação é mais do que real. Isso pode ser visto claramente na saída do comando df:
serp@ubuntu:~$ df -hi Filesystem Inodes IUsed IFree IUse% Mounted on udev 493K 480 492K 1% /dev tmpfs 493K 425 493K 1% /run /dev/xvda1 512K 240K 273K 47% / none 493K 2 493K 1% /sys/fs/cgroup none 493K 2 493K 1% /run/lock none 493K 1 493K 1% /run/shm none 493K 2 493K 1% /run/user /dev/xvdc1 320K 4,1K 316K 2% /var /dev/xvdb1 64K 195 64K 1% /home /dev/xvdh1 4,0M 3,1M 940K 78% /var/www serp@ubuntu:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 2,0G 4,0K 2,0G 1% /dev tmpfs 395M 620K 394M 1% /run /dev/xvda1 7,8G 2,9G 4,6G 39% / none 4,0K 0 4,0K 0% /sys/fs/cgroup none 5,0M 0 5,0M 0% /run/lock none 2,0G 0 2,0G 0% /run/shm none 100M 0 100M 0% /run/user /dev/xvdc1 4,8G 2,6G 2,0G 57% /var /dev/xvdb1 990M 4,0M 919M 1% /home /dev/xvdh1 63G 35G 25G 59% /var/www
Como é claramente visto na seção / var / www, o número de blocos livres no sistema de arquivos e o número de nós livres variam bastante.
Caso eu fique sem inode, não direi feitiços, porque eles não estão (se não estiver certo, me avise). Portanto, para as seções nas quais os arquivos pequenos se multiplicam, você deve selecionar corretamente o sistema de arquivos. Assim, por exemplo, em btrfs, os inodes não podem terminar, porque crie dinamicamente novos, se necessário.