Relire la table de partition sans redémarrer?

Parfois, lors du redimensionnement ou de la manipulation de partitions sur un disque, cfdisk dira:

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

(Cela se produit également avec d'autres outils de partitionnement. Je pense donc qu'il s'agit d'un problème lié à Linux plutôt qu'à un problème de cfdisk.) Pourquoi, pourquoi et pourquoi cela ne se produit-il que de temps en temps et que puis-je faire pour l'éviter?

Remarque: Veuillez supposer qu'aucune des partitions que je suis en train de modifier n'est ouverte, montée ou utilisée.

Mise à jour:

cfdisk demande ioctl(fd, BLKRRPART, NULL)à Linux de relire la table de partition. Deux des autres outils recommandés jusqu'ici ( hdparm -z DEVICE, sfdisk -R DEVICE) font exactement la même chose. La partprobe DEVICEcommande, par contre, semble utiliser un nouvel ioctl appelé BLKPG, qui pourrait être meilleur; Je ne sais pas. (Il se rabat également sur BLKRRPART si BLKPG échoue.)

BLKPG semble être une opération "cette partition a changé; voici la nouvelle taille" et ressemble à l' partprobeappelée individuellement sur toutes les partitions du périphérique transmis. Elle devrait donc fonctionner si les partitions individuelles sont inutilisées. Cependant, je n'ai pas eu l'occasion de l'essayer.

IMHO la réponse la plus fiable / meilleure est

partprobe /dev/sdX

La relecture des informations de la table de partition ne fonctionne pas toujours, mais essayez

hdparm -z /dev/sda

ou

sfdisk -R /dev/sda

Si cela fonctionne, les valeurs dans / proc / partitions changeront.

Sur Centos7:

Selon https://access.redhat.com/solutions/199573

Tu devrais essayer :

partx -u <partition>

Cela a fonctionné pour moi.

Remarque: Veuillez supposer qu'aucune des partitions que je suis en train de modifier n'est ouverte, montée ou utilisée.

Compte tenu de cette hypothèse, la table de partition peut être réanalysée avec succès et le problème ne se posera pas. Si vous obtenez cette erreur, c'est parce que la table de partition est en cours d'utilisation et ne peut donc pas être réanalysée sans créer d'incohérences.

Ce n'est pas basé sur la partition que vous éditez.

Supposons que vous n’ayez qu’un seul disque dur ( /dev/sda) et deux partitions ( /dev/sda1, /dev/sda2) et que vous n’ayez monté qu’une partition ( /dev/sda1). Si vous supprimez ou modifiez tout ce qui concerne une autre partition qui n'est même pas montée ( /dev/sda2), vous obtiendrez l'erreur suivante: la relecture de la table de partition a échoué et le noyau utilise l'ancienne table.

Mais si vous avez deux disques durs ( /dev/sda, /dev/sdb) et qu’aucune des partitions de ( /dev/sdb) n’est utilisée. Ensuite, vous pouvez ajouter / supprimer / redimensionner / éditer des partitions /dev/sdbet elles seront relues sans problème. Mais même si une partition de / dev / sdb a été montée pendant la modification. Ensuite, le noyau continuera d'utiliser l'ancienne table.

Il y a quelques jours, moi-même (l'interlocuteur initial) rencontrais une situation où aucune des autres réponses (y compris la réponse partprobe /dev/sdXactuellement acceptée et la plus votée) ne fonctionnait. Qu'est - ce qui a bien fonctionné, cependant:

blockdev --rereadpt /dev/sdX

(Je ne sais pas pourquoi cela a fonctionné et les autres pas, mais je suis heureux que cela ait fonctionné, car cela m'a évité un redémarrage sur un serveur occupé.)

je suis sur centos 6,5 x64; noyau 2.6.32. et je teste l'astuce fdisk pour redimensionner.

/dev/sda1 /boot
/dev/sda2 /

Toutes les commandes suivantes ne permettent pas au noyau de relire la partition:

• partprobe / dev / sda (avertissement: le noyau n'a pas pu relire ....)
• hdparm -z / dev / sda (BLKRRPART a échoué: périphérique ou ressource occupé)
• blockdev -rereadpt / dev / sda (échec de BLKRRPART: unité ou ressource occupée)
• sfdisk -R / dev / sda (BLKRRPART a échoué: unité ou ressource occupée)

j'ai toujours besoin d'un redémarrage pour que cela fonctionne

Avec tous les points de montage non montés, exécutez Yocto 2.4:

partprobe /dev/sda 

Échec de recharger la table de partition après la suppression des partitions sur le périphérique. Aussi essayé - et ont échoué étaient:

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

Tous ont signalé des erreurs similaires "Erreur BLKRRPART: périphérique ou ressource occupé ..." m'invitant à redémarrer. Est-ce que cet échec des méthodes de travail antérieures est probablement dû au fait que udev est maintenant sous le contrôle de systemd? En pensant à cela, j'ai essayé:

systemctl restart systemd-udevd.service

Et du coup mon disque est à nouveau disponible, sans redémarrage!

Quand une commande comme blockdev --rereadpt /dev/sdXéchoue avec

blockdev: ioctl error on BLKRRPART: Device or resource busy

cela signifie généralement que certaines (anciennes) partitions sont encore utilisées par le noyau.

Causes possibles / solutions:

1. une partition sdX - par exemple sdX1- est toujours montée - vérifiez avec mountet démontez-la
2. /dev/sdX1fait partie d'un raid logiciel - vérifiez cat /proc/mdstatet arrêtez éventuellement les tableaux pertinents, p.ex.mdadm --stop /dev/md126
3. /dev/sdX1fait partie d'un volume physique LVM - vérifier avec pvdisplay/ vgdisplayet éventuellement désactiver avecvgchange
4. /dev/sdX1fait partie d' un certain mappage de périphérique - par exemple via cryptsetup- vérifier /dev/mapperet lsblket éventuellement supprimer l'application (par exemple cryptsetup luksClose)
5. Condition de concurrence avec quelques tests udev - vérifier les processus en cours avec pset éventuellement en tuer un

Si un outil - dire blockdev --rereadptne les généralement similaires ( partx -uv, kpartx, partprobe, kpartprobe) ne parviennent pas d'une manière similaire jusqu'à ce que la cause soit éliminée.

Vous pouvez aussi essayer:

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

(Mais ne fonctionnera pas, voir le commentaire ci-dessous)

kpartx -a <partition> peut être exécuté deux fois sur une partition nouvellement créée .... au lieu de redémarrer le système.

N'oubliez pas de vérifier que le service udev est en cours d'exécution. Ceci est particulièrement utile lorsque partprobe, hdparm, blockdev et diverses autres commandes ne semblent pas avoir d’incidence sur les fichiers de périphérique disponibles dans le répertoire / dev /.

Pour moi non plus partprobeou blockdevsolution élaborée. Bien que celui-ci fonctionne:

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

Si vous lisez la page de manuel pour 'man oracleasm-scandisks', vous remarquerez le texte ci-dessous. oracleasm utilise / proc / partitions comme source de toutes les analyses qu'il effectue. Vous devez répertorier vos périphériques bruts dans / proc / partitions avant de pouvoir effectuer une analyse. Les paramètres Scanorder et Scanexclude que vous placez dans / etc / sysconfig / oracleasm se rapportent aux noms trouvés dans / proc / partitions (!!!!).

---------- homme oracleasm-scandisks ------ ...

COMMENT LA BALAYAGE SE DÉROULE-T-IL? La numérisation se déroule en quatre étapes de base.

   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.