Por que tantos sistemas de arquivos montados em distribuições recentes?

5

Estou usando o Linux em servidores desde 1996 e estou acostumado a ver algo assim:

$ mount
proc on /proc type proc
/dev/sda1 on / type ext3
/dev/sda2 on /usr type ext3
/dev/sdb1 on /home type ext3

(Eu removi as "opções" porque elas não são relevantes aqui.)

Mais recentemente, estou começando a ver:

$ mount
proc on /proc type proc
/dev/sda1 on / type ext3
/dev/sda2 on /usr type ext3
/dev/sdb1 on /home type ext3
devtmpfs on /dev type devtmpfs 
tmpfs on /run type tmpfs 
tmpfs on /run/lock type tmpfs 
sysfs on /sys type sysfs
tmpfs on /run/shm type tmpfs 
devpts on /dev/pts type devpts 

Acho que posso entender alguns desses itens adicionais, embora todos provavelmente se sobreponham a proc ...

Eu recentemente peguei uma imagem ISO ao vivo de uma distribuição desktop (Linux Mint neste caso em particular, mas eu vi no Debian, Kali, e outros), e há essa loucura:

$ mount
sysfs on /sys type sysfs 
proc on /proc type proc 
udev on /dev type devtmpfs 
devpts on /dev/pts type devpts 
tmpfs on /run type tmpfs 
/dev/sda1 on / type ext4 
securityfs on /sys/kernel/security type securityfs 
tmpfs on /dev/shm type tmpfs 
tmpfs on /run/lock type tmpfs 
tmpfs on /sys/fs/cgroup type tmpfs 
cgroup on /sys/fs/cgroup/systemd type cgroup 
pstore on /sys/fs/pstore type pstore 
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup 
cgroup on /sys/fs/cgroup/pids type cgroup 
cgroup on /sys/fs/cgroup/hugetlb type cgroup 
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup 
cgroup on /sys/fs/cgroup/blkio type cgroup 
cgroup on /sys/fs/cgroup/freezer type cgroup 
cgroup on /sys/fs/cgroup/perf_event type cgroup 
cgroup on /sys/fs/cgroup/cpuset type cgroup 
cgroup on /sys/fs/cgroup/memory type cgroup 
cgroup on /sys/fs/cgroup/devices type cgroup 
systemd-1 on /proc/sys/fs/binfmt_misc type autofs 
mqueue on /dev/mqueue type mqueue 
debugfs on /sys/kernel/debug type debugfs 
hugetlbfs on /dev/hugepages type hugetlbfs 
fusectl on /sys/fs/fuse/connections type fusectl 
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc 
cgmfs on /run/cgmanager/fs type tmpfs 
tmpfs on /run/user/1000 type tmpfs 
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse 

Qual é o motivo dessa proliferação de "montagens"? São coisas como cgroups particularmente convenientes para visualizar como sistemas de arquivos "montados" em vez de acessá-los através de, e. APIs programáticas?

    
por Christopher Schultz 21.12.2017 / 00:07

1 resposta

3

Esta é uma escolha do tipo de API.

Em sistemas antigos, era comum usar dispositivos e IOCTL nesses dispositivos (por exemplo, para criar terminais virtuais). O problema era que ele dependia do uso do número para ter acesso a um serviço específico, portanto não era fácil melhorar / atualizar. Além disso, o mesmo número de solicitação pode ter um significado completamente diferente em outro dispositivo; portanto, ao renomear dispositivos (mais descritivos, sistemas virtuais, etc.), é possível fornecer o comando incorreto (por exemplo, confundir o tipo de dispositivo a ser fornecido). um programa).

Então havia outras alternativas. Algum tempo, novos syscall foram criados, mas isso principalmente para casos genéricos, e também não é ideal para criar muitos novos syscalls. /proc também se tornou uma interface comum, mas com algum problema porque a interface desse sistema de arquivos (lado do kernel) é a mesma para todos os serviços. A APCI e a rede usaram extensivamente essa interface. Houve algum problema sobre a remoção de módulos enquanto outro programa tinha acesso ao seu arquivo no proc. Agora os módulos (e, portanto, removê-los para liberar memória) não são tanto um problema

Poucas tentativas de usar o soquete de rede foram usadas, mas não tão convenientes para usos únicos.

Portanto, agora é mais fácil criar novos sistemas de arquivos e dar mais liberdade aos drivers / serviços sobre como implementá-los. Há também uma vantagem, apenas cat e echo podem ser usados para obter e extrair dados. mais fácil de testar e usar novos recursos.

    
por 21.12.2017 / 10:15