API do kernel do sistema de arquivos

Question

Assumindo que todos os sistemas de arquivos são específicos, como ferramentas como ls, touch, cat, etc. interagem com elas? Suponho que 'ls' não saiba detalhes específicos sobre o btrfs, por exemplo, mas lê entradas de diretório de qualquer maneira. Quando algum processo grava um arquivo, ele não sabe sobre os específicos do alocador de bloco para um determinado sistema de arquivos, mas, de qualquer forma, o arquivo é escrito com êxito.
Existe algum tipo de API do kernel que oculta a implementação do sistema de arquivos subjacente dos processos? Não é muito complexo criar um sistema de arquivos simples personalizado para fins acadêmicos e escrever programas para manipulá-lo (mkfs, fsck, etc), mas como dizer ao kernel sobre a implementação do sistema de arquivos, para que outros processos possam usá-lo? > EDIT:
Eu entendo syscalls no espaço do usuário, mas o que eu estou realmente interessado é o que está acontecendo depois disso, no espaço do kernel.

    

Answer 1

Em qualquer sistema POSIX, a interface entre aplicativos e o kernel são algumas chamadas de função: open , read , write , close , etc. Um aplicativo como cat chama essas funções; não importa como as funções são implementadas sob o capô.

Em sistemas Unix, essas funções são, na verdade, chamadas do sistema : o aplicativo chama o kernel . Dentro do kernel, uma arquitetura típica é ter uma camada VFS , que lida com tarefas que são independentes do formato do sistema de arquivos (como como localizar o sistema de arquivos apropriado, permissões, bloqueio, etc.). Depois de determinar em qual sistema de arquivos o arquivo está localizado, a camada VFS passa a operação para o driver específico do sistema de arquivos.

Você pode observar a interface entre os aplicativos e o kernel com uma ferramenta como strace no Linux ou seu equivalente em outros Unix plataformas ( trace , truss ,…). Exemplo (omitindo a parte do rastreio correspondente à inicialização e a limpeza final de cat ):

$ strace cat foo
…
open("foo", O_RDONLY)                   = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=6, ...}) = 0
fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8b9ea14000
read(3, "hello\n", 131072)              = 6
write(1, "hello\n", 6hello
)                  = 6
read(3, "", 131072)                     = 0
munmap(0x7f8b9ea14000, 139264)          = 0
close(3)                                = 0
…

Você pode ver cat chamando open , read e close no arquivo. Ele também chama fstat e fadvise64 , acho que apenas para otimizações de desempenho.

A interface entre o VFS e o driver do sistema de arquivos não pode ser espionada tão facilmente.

Programas como mkfs e fsck não passam pela interface de sistema de arquivos do kernel, porque eles não funcionam em arquivos, eles trabalham em áreas de armazenamento. Eles acessam o dispositivo de bloco que contém o sistema de arquivos diretamente.

Se você quiser adicionar suporte para um novo sistema de arquivos, você precisa escrever um driver para ele. Existem duas maneiras de fazer isso.

• Você pode escrever um driver que seja executado no kernel; Isso proporciona a você o melhor desempenho e é a única maneira de implementar algum recurso (por exemplo, controle de acesso refinado). Mas também é mais difícil de depurar (se o seu driver tiver um bug, você provavelmente precisará reinicializar; se tiver sorte, poderá visualizar um rastreamento de erro e talvez até atrasar a reinicialização até salvar seus dados - melhor fazer isso em uma máquina virtual). Procure a documentação do kernel da sua variante Unix para ver qual interface você precisa implementar.
• Como alternativa, você pode usar o FUSE , que é um driver de sistema de arquivos que encaminha todos os pedidos de volta para fora do kernel, então Cada driver do sistema de arquivos é implementado como um processo. Se o sistema de arquivos estiver com problemas, apenas mate o processo do driver do sistema de arquivos e o resto do sistema operacional sobreviverá. Para aprender como escrever um sistema de arquivos FUSE, veja os exemplos e leia tutoriais como Sumit Singh's .

Answer 2

O sistema Unix / Linux oferece as chamadas do sistema POSIX open (2) / close (2) / read (2) / write (2) e stat (2) e algumas funções de nível superior como o opendir (3) / closedir (3) / readdir (3), que são suficientes para escrever as ferramentas declaradas (é mais fácil usar os wrappers C). Parte do trabalho duro do kernel é precisamente fazê-los funcionar nos vários sistemas de arquivos oferecidos, e fazer todo o trabalho em qualquer dispositivo que eles possam estar residindo.

    

Answer 3

Para a maioria das ferramentas, a camada subjacente é a Biblioteca padrão C ("libc"). libc fornece várias rotinas de manipulação de arquivos de baixo nível, como open , read e write . Essas rotinas, por sua vez, fazem interface com a camada do sistema de arquivos no kernel, que fica no topo da camada de dispositivo de blocos do kernel, os drivers de dispositivos e, finalmente, o hardware.

Uma implementação da libc é a biblioteca GNU C ("glibc"). Talvez você queira dar uma olhada na documentação oficial , que descreve as funções de arquivo de baixo nível de glibc em mais detalhes.