Reler a tabela de partição sem reiniciar?

Às vezes, ao redimensionar ou mexer com partições em um disco, o cfdisk dirá:

Wrote partition table, but re-read table failed. Reboot to update table.

(Isso também acontece com outras ferramentas de particionamento, então estou pensando que esse é um problema de Linux e não de cfdisk.) Por que isso e por que isso acontece apenas às vezes e o que posso fazer para evitá-lo?

Nota: Assuma que nenhuma das partições que estou editando esteja aberta, montada ou em uso.

Atualizar:

O cfdisk usa ioctl(fd, BLKRRPART, NULL)para dizer ao Linux para reler a tabela de partição. Duas das outras ferramentas recomendadas até agora ( hdparm -z DEVICE, sfdisk -R DEVICE) fazem exatamente a mesma coisa. O partprobe DEVICEcomando, por outro lado, parece usar um novo ioctl chamado BLKPG, que pode ser melhor; Eu não sei. (Ele também recai no BLKRRPART se o BLKPG falhar.)

O BLKPG parece ser uma operação "esta partição foi alterada; aqui está o novo tamanho" e parecia ser partprobechamada individualmente em todas as partições do dispositivo aprovadas; portanto, deve funcionar se as partições individuais não forem usadas. No entanto, não tive a oportunidade de experimentá-lo.

IMHO a resposta mais confiável / melhor é

partprobe /dev/sdX

Reler as informações da tabela de partições nem sempre funciona, mas tente

hdparm -z /dev/sda

ou

sfdisk -R /dev/sda

Se funcionar, os valores em / proc / partitions serão alterados.

No Centos7:

De acordo com https://access.redhat.com/solutions/199573

Você deveria tentar :

partx -u <partition>

Funcionou para mim.

Nota: Por favor, assuma que nenhuma das partições que estou editando está aberta, montada ou em uso.

Dada essa suposição, a tabela de partição pode ser verificada novamente com êxito e o problema não surgirá. Se você está recebendo esse erro, é porque a tabela de partição está atualmente em uso e, portanto, não pode ser verificada novamente sem criar inconsistências.

Não é baseado na partição que você está editando.

Suponha que você tenha apenas um disco rígido ( /dev/sda) e duas partições ( /dev/sda1, /dev/sda2) e tenha montado apenas uma partição ( /dev/sda1). Se você excluir ou alterar algo sobre outra partição que nem esteja montada ( /dev/sda2), você receberá o erro de que a leitura da tabela de partição falhou e o kernel usará a tabela antiga.

Mas se você tiver dois discos rígidos ( /dev/sda, /dev/sdb) e nenhuma das partições de ( /dev/sdb) estiver em uso. Em seguida, você pode adicionar / excluir / redimensionar / editar partições /dev/sdbe elas serão relidas sem nenhum problema. Mas mesmo que uma partição do / dev / sdb tenha sido montada durante a alteração. Então o kernel continuará usando a tabela antiga.

Eu (o questionador original) tive uma situação há alguns dias atrás, quando nenhuma das outras respostas (incluindo partprobe /dev/sdX, atualmente, a resposta aceita e a mais votada) funcionou. O que funcionou, no entanto, foi o seguinte:

blockdev --rereadpt /dev/sdX

(Não sei por que isso funcionou e os outros não, mas estou feliz que funcionou, pois me salvou de uma reinicialização em um servidor ocupado.)

estou no centos 6.5 x64; kernel 2.6.32. e estou testando o truque do fdisk para redimensionar.

/dev/sda1 /boot
/dev/sda2 /

Todos os comandos a seguir não fizeram a releitura do kernel:

• partprobe / dev / sda (aviso: o kernel falhou ao reler ....)
• hdparm -z / dev / sda (BLKRRPART falhou: dispositivo ou recurso ocupado)
• blockdev -rereadpt / dev / sda (BLKRRPART falhou: dispositivo ou recurso ocupado)
• sfdisk -R / dev / sda (falha de BLKRRPART: dispositivo ou recurso ocupado)

eu ainda preciso de uma reinicialização para fazê-lo funcionar

Com todos os pontos de montagem desmontados, execute o Yocto 2.4:

partprobe /dev/sda 

Ainda não foi possível recarregar a tabela de partições após a exclusão das partições no dispositivo. Também tentaram - e falharam foram:

udevadm trigger --subsystem-match=block; udevadm settle
hdparm -z /dev/sda
blockdev --rereadpt /dev/sda

Todos relataram erros semelhantes "BLKRRPART falhou: dispositivo ou recurso ocupado ..." instruindo-me a reiniciar. Essa falha nos métodos de trabalho anteriores possivelmente se deve ao fato de o udev estar agora sob controle do systemd? Pensando nessas linhas, tentei:

systemctl restart systemd-udevd.service

E de repente meu disco está disponível novamente, sem uma reinicialização!

Quando um comando como blockdev --rereadpt /dev/sdXfalha com

blockdev: ioctl error on BLKRRPART: Device or resource busy

isso geralmente significa que alguma partição (antiga) ainda é de alguma forma usada pelo kernel.

Possíveis causas / correções:

1. uma partição sdX - digamos sdX1- ainda está montada - verifique mounte desmonte
2. /dev/sdX1faz parte de uma invasão de software - verifique cat /proc/mdstate possivelmente interrompa as matrizes relevantes, por exemplomdadm --stop /dev/md126
3. /dev/sdX1faz parte de um volume físico LVM - verifique com pvdisplay/ vgdisplaye possivelmente desative comvgchange
4. /dev/sdX1faz parte de algum mapeamento de dispositivo - por exemplo, via cryptsetup- check /dev/mappere, lsblke possivelmente remove o mapeamento (por exemplo cryptsetup luksClose)
5. Condição de corrida com algumas sondagens no udev - verifique os processos em execução pse, possivelmente, mate um

Se uma ferramenta - dizer blockdev --rereadptnão aqueles geralmente semelhantes, como ( partx -uv, kpartx, partprobe, kpartprobe) falhar de forma semelhante até que a causa raiz é eliminado.

Você também pode tentar:

echo 1 > /sys/block/sdX/device/rescan

(Mas não vai funcionar, veja o comentário abaixo)

kpartx -a <partition> pode ser executado duas vezes na partição recém-criada .... em vez de reiniciar o sistema.

Lembre-se de verificar se o serviço udev está em execução. Isso é especialmente útil quando partprobe, hdparm, blockdev e vários outros comandos não parecem fazer diferença em quais arquivos de dispositivo estão disponíveis no diretório / dev /.

Para mim nem partprobeou blockdevsolução funcionou. Embora, este funcione:

udevadm settle --exit-if-exists=/dev/sdb1

Se você ler a página de manual de 'man oracleasm-scandisks', anote o texto abaixo. O oracleasm está usando / proc / partitions como a fonte de todas as varreduras realizadas. Você deve ter seus dispositivos brutos listados em / proc / partitions antes de poder fazer um scandisk. Os parâmetros Scanorder e Scanexclude que você coloca em / etc / sysconfig / oracleasm estão relacionados aos nomes encontrados em / proc / partitions (!!!!).

---------- man oracleasm-scandisks ------ ...

COMO A DIGITALIZAÇÃO ACONTECE A digitalização prossegue em quatro estágios básicos.

   First, the list of disks to scan is created. If disks were specified on the command line, this is the list.
   If not, /proc/partitions is read, and each block device is added, subject to the -o and -x options.

   Second, the partition tables of each disk in the scan are reloaded unless the -s option was specified. Any
   disks that no longer exist are dropped.

   Third, the list of disks is recreated based on the new partition tables.

   Finally, each disk in the list is checked to see if it is marked for ASM use. Disks that are marked are
   instantiated.