Sistemas de arquivos implementam alguma API do kernel. Portanto, eles precisam fornecer funções para abrir um arquivo por nome, gravar em um arquivo, ler em um arquivo e fechar um arquivo novamente (basta seguir essas operações básicas).
O kernel fornece funções para ler um setor e escrever um setor.
A mágica intermediária é feita pelo sistema de arquivos "driver". Portanto, se um programa deseja abrir um arquivo, o kernel passa essa solicitação para o driver do sistema de arquivos. Em seguida, o driver lê os metadados do sistema de arquivos e localiza a entrada do arquivo. A entrada contém informações do sistema de arquivos, como propriedade do usuário e do grupo, permissões, tempo de acesso e muito mais, e, claro, informações sobre o setor em que o arquivo está localizado no disco (vamos ignorar a fragmentação aqui).
Portanto, se você pegar toda a partição e movê-la para outro local no disco, todos os números de setor armazenados terão um deslocamento, mas o sistema de arquivos não conhece esse deslocamento. Portanto, se um programa tentar abrir um arquivo, o sistema de arquivos usará o número do setor conforme armazenado nos metadados do sistema de arquivos para ler o conteúdo do arquivo. Mas, como todo o sistema de arquivos é movido vários setores, os dados lidos não corresponderão ao conteúdo do arquivo e o arquivo estará corrompido. O mesmo vale para todo o resto do sistema de arquivos também.
O kernel não sabe nada sobre isso. Um motorista pede para ler um setor. O kernel não sabe se o número do setor deve ter um deslocamento ou não. Portanto, isso é algo que deve ser implementado em todos os drivers do sistema de arquivos.
Agora imagine um sistema de arquivos (legado) que usa 16 bits para endereçar setores. Vamos supor que um setor tenha 512 bytes. Portanto, o tamanho máximo do sistema de arquivos pode ser de 32 MiB. Se você quiser expandir ainda mais o sistema de arquivos, ele precisará alterar o tamanho de um setor endereçável de 512 bytes para 1024 bytes. Mas mesmo agora, o sistema de arquivos está cheio, porque todos os números do setor são usados. Portanto, o programa de expansão do sistema de arquivos precisa varrer todos os arquivos e copiar dois setores, que têm 1024 bytes de tamanho, mas apenas 512 bytes, em um setor para que um setor esteja cheio (novamente) e o outro possa ser liberado.
Agora imagine que isso deve ser feito enquanto o sistema de arquivos estiver montado e os programas estiverem lendo e gravando com alegria de e para o disco. Isso adiciona bastante complexidade ao driver do sistema de arquivos, que é necessário apenas para esse caso de uso especial. Portanto, é mais fácil simplesmente redimensionar apenas um sistema de arquivos quando ele não está montado.
Além disso, há mais magia sob o capô. Você pode, por exemplo, criar um arquivo, abri-lo e removê-lo. O arquivo não tem mais uma representação no sistema de arquivos (não tem nome de arquivo), mas como um descritor aberto ainda existe, o arquivo ainda pode ser lido e gravado. Se o programa que contém o descritor fork s, até os filhos podem acessar esse arquivo à medida que herdam o descritor. Assim que todos os descritores abertos para esse arquivo forem close d, o sistema de arquivos marcará os setores como não utilizados, prontos para serem usados em novos arquivos.
Então, se você unmount o sistema de arquivos e, em seguida, mount novamente, esses arquivos sumiram. E o programa está preso.