Por que a montagem acontece em um diretório existente?

Um diretório existente é necessário como um ponto de montagem .

$ ls
$ sudo mount /dev/sdb2 ./datadisk
mount: mount point ./datadisk does not exist
$ mkdir datadisk
$ sudo mount /dev/sdb2 ./datadisk
$

Acho confuso, pois sobrepõe o conteúdo existente do diretório. Existem dois conteúdos possíveis do diretório do ponto de montagem que podem ser alternados inesperadamente (para um usuário que não está executando a montagem).

Por que não mountacontece em um diretório recém-criado? É assim que os sistemas operacionais gráficos exibem mídia removível. Ficaria claro se o diretório está montado (existe) ou não está montado (não existe). Tenho certeza de que existe um bom motivo, mas ainda não o descobri.

Este é um caso de um detalhe de implementação que vazou.

Em um sistema UNIX, todo diretório consiste em uma lista de nomes mapeados para números de inode . Um inode contém metadados que informam ao sistema se é um arquivo, diretório, dispositivo especial, pipe nomeado etc. Se for um arquivo ou diretório, também informa ao sistema onde encontrar o conteúdo do arquivo ou diretório no disco. A maioria dos inodes são arquivos ou diretórios. A -iopção para lslistar os números dos inodes.

A montagem de um sistema de arquivos pega um inode de diretório e define um sinalizador na cópia em memória do kernel para dizer "na verdade, ao procurar o conteúdo desse diretório, observe esse outro sistema de arquivos" (consulte o slide 10 desta apresentação ). Isso é relativamente fácil, pois altera um único item de dados.

Por que ele não cria uma entrada de diretório para você apontar para o novo inode? Há duas maneiras de implementar isso, ambas com desvantagens. Uma é escrever fisicamente um novo diretório no sistema de arquivos - mas isso falhará se o sistema de arquivos for somente leitura! A outra é adicionar a cada processo de listagem de diretórios uma lista de coisas "extras" que realmente não existem. Isso é complicado e potencialmente gera um pequeno impacto no desempenho em todas as operações de arquivo.

Se você deseja pontos de montagem criados dinamicamente, o automountsistema pode fazer isso. Sistemas de arquivos não-disco especiais também podem criar diretórios à vontade, por exemplo proc, sys, devfse assim por diante.

Editar: veja também a resposta para O que acontece quando você 'monta' uma pasta existente com conteúdo?

Se mount(2) necessário, a criação de um novo diretório para ser o ponto de montagem, você não poderá montar nada em um sistema de arquivos somente leitura. Isso seria idiota, para que possamos descartar isso.

Se mount opcionalmente criou um novo diretório para ser o ponto de montagem, isso seria estranho. Não é como montar / desmontar acontecer o tempo todo, portanto, colocar lógica extra no kernel para executar essas duas etapas com uma única chamada do sistema não seria uma aceleração importante. Apenas deixe espaço para o usuário fazer uma mkdir(2)chamada do sistema, se desejar. A resposta de Dmitry aponta que mount(2)fazer as duas coisas a tornaria não atômica. E você iria querer um argumento extra para mount(2)com bandeiras do modo como open(2)toma, para O_CREAT, O_EXCL, etc. Seria apenas ser bobo em comparação a deixar o espaço do usuário fazê-lo.

Ou talvez você estivesse perguntando sobre ter mount(8)(o programa tradicional que faz mount(2)chamadas do sistema) fazer isso? Isso seria possível, mas já existe algo perfeitamente bom mkdir(1)para o trabalho, e o design do Unix é sobre boas ferramentas pequenas que podem ser combinadas. Se você deseja uma ferramenta que faça as duas coisas, é fácil escrever um script de shell para criar essa ferramenta com duas ferramentas mais simples. (Ou, como muru comentou, udisksctljá faz isso, para que você não precise escrevê-lo.) Além disso, o normal do Linux a mount(8)partir do util-linux suporta o mount -o x-mount.mkdir[=mode]uso de sua x-sintaxe para opções de espaço do usuário, em vez de opções a serem passadas para o sistema de arquivos.

Agora, a pergunta mais interessante: por que deve haver um diretório no sistema de arquivos pai?

Como a resposta de pjc50 aponta (sem relação, mesmo que ele tenha minhas iniciais!), Ter pontos de montagem exibidos nas listagens de diretório exigiria uma verificação extra em todos os itens readdir().

Ter pontos de montagem como diretórios no diretório que os contém (no FS pai) é um bom truque. readdir()não precisa perceber que é um ponto de montagem. Isso só acontece se o ponto de montagem for usado como um componente do caminho. É claro que a resolução do caminho precisa verificar a tabela de montagem para todos os componentes de diretório de um caminho.

A montagem no diretório existente faz uma chamada para mountpraticamente atômica: ela é bem-sucedida ou falha, pelo menos da perspectiva do usuário. Se mountfosse necessário criar o ponto de montagem, ele teria dois pontos de falha, tornando impossível garantir uma reversão limpa. Imagine o seguinte cenário:

1. mount cria com êxito o ponto de montagem
2. mount tenta montar um novo sistema de arquivos nesse diretório, mas falha
3. mount tenta remover o ponto de montagem, mas falha

O sistema acaba com um efeito colateral de uma falha mount.

Aqui está mais um:

1. umount desmonta com sucesso um sistema de arquivos
2. umount tenta remover o ponto de montagem, mas falha

Agora, deve umountretornar sucesso ou fracasso?

Outro caso que pode ocorrer:

Quando você inicializa, uma imagem básica somente leitura é carregada no diretório raiz. Então, você gostaria de substituí-lo quando quiser montar uma raiz real. Então você pode imaginar que o mount syscall apenas troque o roponto de montagem para rw.

Aqui, vamos imaginar que você tenha um problema no sistema de arquivos no ponto de montagem raiz, você gostaria de tentar consertá-lo. Com a sobreposição de montagem, é possível desmontar o sistema de arquivos e usar fscka imagem básica para resolvê-lo.

Esse recurso também pode ser útil em sistemas que precisam de segurança forte para rastrear as alterações entre uma ropartição e uma rw.

Eu sempre me perguntei isso também.

Um invólucro simples, como:

#!/bin/sh
eval "mkdir -p \"\$$#\"" 
/bin/mount "$@"  

salvo como um script executável nomeado mountem um diretório que substitui o /binseu PATH deve cuidar disso se isso o incomodar demais

(Antes de executar o mountbinário real , ele cria um diretório nomeado após o último argumento mount, se esse diretório ainda não existir.)

Como alternativa, se você não deseja que invocações com falha do mountwrapper criem diretórios, você pode:

#!/bin/sh
set -e
eval "lastArg=\"\$$#\""
test -d "$lastArg" || { mkdir "$lastArg"; madeDir=1; }
/bin/mount "$@"  ||  {  test -z "$madeDir" || rmdir "$lastArg"; }