Por que não é possível redimensionar / mover partições montadas (não lógicas) em tempo de execução?

3

Durante a pesquisa, por que não é possível redimensionar uma partição montada, encontrei principalmente respostas como esta:

  • It is filesystem and partition dependant, different flesystems and partitions will use different methods. - by Javier Rivera

  • First you have to expand the underlying block device. If you are using a conventional partition on a single hard disk, this is not possible. LVM and mdadm can expand the block device, then you can run resize2fs to expand the fs ( assuming it is ext[234] ). - by psui

  • It really depends on the filesystem you are using [...] but it is highly NOT recommended to resize a mounted, usable partition. - by Luis Alvarado

Non está explicando porque não é possível (porque ninguém perguntou), apenas mencionando, que ele é dependente do sistema de arquivos, ou não é possível se a partição não for um volume lógico.

Eu não tenho conhecimento sobre o funcionamento interno do processo de montagem e manipulação de partição / sistema de arquivos de um sistema operacional, mas eu me pergunto por que não é possível para o programa de particionamento solicitar ao usuário fechar tudo é processos e depois disso mantém os processos restantes e uma cópia dos dados que eles precisam na RAM e desmonta a partição para redimensioná-la.

    
por Senkaku 10.08.2013 / 23:28

2 respostas

2

Os 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 de usuário e 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 para 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. Então, 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 seja liberado.

Agora imagine que isso deve ser feito enquanto o sistema de arquivos está montado e os programas estão 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. Por isso, é mais fácil simplesmente redimensionar apenas um sistema de arquivos quando 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 possui nome de arquivo), mas como um descritor aberto ainda existe, o arquivo ainda pode ser lido e gravado. Se o programa contiver o descritor fork s, até os filhos poderão acessar esse arquivo à medida que herdarem 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.

Se você unmount do sistema de arquivos e mount novamente, esses arquivos desaparecerão. E o programa está preso.

    
por 11.08.2013 / 02:15
3

Na verdade, é possível redimensionar muitos sistemas de arquivos modernos enquanto eles estão montados (embora geralmente apenas ao aumentar seu tamanho). Por exemplo:

  • De man resize2fs : "O programa resize2fs ... pode ser usado para ampliar ou reduzir um sistema de arquivos desmontado ... Se o sistema de arquivos estiver montado, ele pode ser usado para expandir o tamanho do sistema de arquivos montado ... "
  • De man xfs_growfs : "O sistema de arquivos deve ser montado para ser desenvolvido".
  • De man mount : "Opções de montagem para jfs ... resize = valor ... Redimensione o volume para blocos valor . O JFS suporta apenas o crescimento de um volume, não encolhendo. "
  • De Divertimento do BTRFS : "E sim, é um redimensionamento on-line, não há necessidade de desmontar / encolher / Então não há downtimes! "

AFAIK, o ReiserFS não pode ser redimensionado quando montado.

A capacidade de redimensionar um volume sem desmontá-lo é extremamente importante para servidores de missão crítica e afins - um provedor de hospedagem de Web (por exemplo) não pode pagar o tempo de inatividade necessário para colocar um sistema de arquivos offline para redimensioná-lo depois de adicionar um novo disco a um array RAID. É por isso que muitos sistemas de arquivos modernos suportam esse recurso.

Dito isso, o GParted não pode redimensionar partições sem desmontá-las. Não tenho certeza, mas suspeito que isso tenha mais a ver com o lado da partição da equação do que com o lado do sistema de arquivos; ou pode ser que os desenvolvedores do GParted estivessem sendo conservadores e definindo os requisitos de menor denominador comum (ou seja, para o ReiserFS).

Definitivamente, é mais fácil lidar com o redimensionamento de sistemas de arquivos quando eles são armazenados em uma configuração do LVM. Este tipo de configuração significa que você nunca terá que mover o ponto inicial de um sistema de arquivos, para que você possa aumentar um volume lógico e o sistema de arquivos que ele contém dezenas de vezes, se necessário, até mesmo no espaço ocupado pelos sistemas de arquivos que estavam presentes mas que você apagou. O LVM também foi projetado com mudanças dinâmicas para os volumes lógicos em mente, enquanto o manuseio das partições pelo kernel é mais estático. Se você ajusta frequentemente seus sistemas de arquivos, você deve definitivamente procurar pelo LVM. Há um pouco de curva de aprendizado para o LVM, mas vale a pena o incômodo para quem faz manipulações avançadas ou freqüentes do sistema de arquivos.

    
por 11.08.2013 / 06:42