Como faço para mover um sistema de arquivos ext4 de / dev / sdb para / dev / sdb1?

Question

De alguma forma eu tenho um sistema de arquivos ext4 em / dev / sdb. Eu esperava que fosse / dev / sdb1.

Eu posso montá-lo manualmente; Eu posso acessar os dados; Eu posso referenciá-lo em / etc / fstab; etc, mas eu quero em uma partição padrão.

Não quero perder os dados e não há espaço suficiente na unidade para duplicá-los em outra partição. Não é um monte de dados: eu sempre posso movê-lo para um dispositivo externo, consertar o fs, depois movê-lo de volta, mas agora estou curioso:)

Existe um método para remapear ou mover os dados para / dev / sdb1 (que, a partir de agora, não existe)?

O fdisk fornece o seguinte:

$ sudo fdisk /dev/sdb1
fdisk: cannot open /dev/sdb1: No such file or directory

$ sudo fdisk /dev/sdb
Device /dev/sdb already contains a ext4 signature.
The signature will be removed by a write command.

Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0x4096cdf8.

Command (m for help): p
Disk /dev/sdb: 200GiB, 214748364800 bytes, 419430400 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x4096cdf8

Sim, esta é uma unidade muito pequena! Estou usando o Debian Stretch em um VirtualBox vm.

A resposta para df:

$ df -h
Filesystem Size  Used  Avail  Use%  Mounted on
/dev/sdb   196G  116G   71G    63%  /media/mymountdir

Eu entendo que, como afirma @MarkPlotnick, eu posso fazer isso de maneira indolor, já que estou em uma vm. Mas eu gostaria de saber se existe um método baseado em cli. Obrigado!

    

Answer 1

Você pode escrever um sistema de arquivos ext4 (ou qualquer outro) em um disco inteiro (em vez de uma partição), mas é claro que isso significa que não há tabela de partições; você está usando todo o dispositivo bruto.

Isto é possível se você começar com um disco com uma tabela de partições, e então equivocadamente (com a informação do disco ainda na memória) formatá-lo como ext4, sobrescrevendo a tabela de partição (ex .: mkfs.ext4 /dev/sdb em vez de mkfs.ext4 /dev/sdb1 ). O resultado é um disco sem uma tabela de partição válida (agora tem um bloco ext4 begin), mas o sistema de arquivos armazena seu tamanho independentemente, então ainda funcionará (isso também é feito em alguns discos externos). Você pode montar o dispositivo da mesma forma que uma partição - basta usar sdb onde você teria usado sdb1 .

O que segue é arriscado como todo o inferno, como você pode imaginar. Você já deve ter um backup e, se não tiver, obtenha um agora . Por outro lado, se você não tiver um backup, isso significa que você não está muito interessado nesses dados (que estava em risco de falha de hardware, falha de software ou, dependendo do cenário, café derramado, cano de ruptura , roubo e desastres naturais e não naturais), por isso, se o pior acontecer, ainda assim não haveria grandes danos.

UPDATE : se você tiver o espaço em algum lugar, faça o backup , reformate e reinstale. Mesmo tempo exato que o método de mudança, mas cem por cento mais segurança de dados. E se você não excluir a cópia de backup, você terá uma imagem de backup de atualização lançada gratuitamente.

Primeiro passo: redimensione o sistema de arquivos ext4 para que seja um cilindro de disco inteiro mais curto. Obtenha o tamanho do cilindro em hdparm , pois a tabela de partição, bem, simplesmente não está lá (o fdisk informará o número total de setores, e não como eles estão organizados). Em alguns drivers USB externos, talvez seja necessário tentar ler a marca e o modelo do disco e usá-lo para procurar informações na Internet. Drivers SATA devem estar OK.

Agora que você sabe quanto, você pode redimensionar o sistema de arquivos e deslocar toda a partição "para a direita", no final do disco, liberando um cilindro no início, que é onde a tabela de partições e start blank space go (não sei exatamente por que nos discos do LBA sdX1 deve iniciar um cilindro - ou uma faixa - após a tabela de partições, mas nunca achei que vale a pena experimentar).

Para mudar a partição, você pode usar uma estratégia de buffer excessivamente perigosa ou a opção reverse para dd_rescue (parece ter visto algum relatório de bug no qual esta opção foi dita não funcionar).

Você pode querer experimentar um arquivo grande - digamos, um gigabyte - para ver se as duas opções funcionam; deslocar o conteúdo para que ele mova dados de dezesseis megabytes do início dentro do arquivo, deixando o tamanho do arquivo igual; em seguida, inspecione o conteúdo para verificar se foi o que aconteceu. Depois, repita com /dev/sdb e as compensações apropriadas.

Depois disso, use fdisk para recriar a tabela de partições.

Boa sorte!

    

Answer 2

Se você criou o sistema de arquivos no dispositivo de bloco real, como aparece, fdisk não será seu amigo até que seus dados sejam movidos para outro lugar. Você terá que montar o sistema de arquivos, copiar os dados e depois desmontá-los. Você pode usar fdisk para particionar corretamente o dispositivo de bloco, usar mkfs na partição, montá-lo e mover seus dados de volta:

$ sudo -s
# mkdir -p /mnt/export
# mount /dev/sdb /mnt/export
# exit
$ rsync -a /mnt/export/ /path/to/backup/
$ sudo -s
# umount /mnt/export
# fdisk /dev/sdb  # create your partitions
# mount /dev/sdb1 /mnt/export
# exit
$ rsync -za /path/to/backup/ /mnt/export/

    

Answer 3

Para uma máquina virtual, o que você já tem não é uma configuração irracional. Permite que mais disco seja adicionado com facilidade ao seu sistema.

Considere o método se você tiver uma tabela de partições:

• Administrador aumenta a alocação de disco para sua VM
• Você verifica novamente o disco virtual ou reinicializa sua VM
• Você exclui a entrada da partição e a recria no novo tamanho maior
• Você redimensiona seu sistema de arquivos

O terceiro passo - o complicado - pode ser omitido se o seu sistema de arquivos estiver diretamente no disco sem uma tabela de partição.