재부팅하지 않고 파티션 테이블을 다시 읽습니까?

때때로 디스크의 파티션 크기를 조정하거나 다른 방식으로 뭉개면 cfdisk는 다음과 같이 말합니다.

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

(이것은 다른 파티셔닝 도구에서도 발생하므로 이것이 cfdisk 문제가 아닌 Linux 문제라고 생각합니다.) 이것이 왜 발생하는 이유는 무엇이며 가끔 발생하는 이유는 무엇이며,이를 피하기 위해 어떻게해야합니까?

참고 : 실제로 편집중인 파티션이 열려 있거나 마운트되어 있거나 사용중인 것으로 가정하지 마십시오.

최신 정보:

cfdisk는 ioctl(fd, BLKRRPART, NULL)파티션 테이블을 다시 읽도록 Linux에 지시 하는 데 사용 됩니다. 지금까지 권장 된 다른 도구 중 두 개 ( hdparm -z DEVICE, sfdisk -R DEVICE)는 정확히 동일한 기능을 수행합니다. 반면이 partprobe DEVICE명령은 BLKPG라는 새로운 ioctl을 사용하는 것 같습니다. 모르겠어요 (BLKPG가 실패하면 BLKRRPART로 대체됩니다.)

BLKPG는 "이 파티션이 변경되었습니다. 여기에 새로운 크기입니다"작업 인 것 같습니다. partprobe전달 된 장치의 모든 파티션에서 개별적으로 호출 된 것처럼 보이 므로 개별 파티션을 사용하지 않으면 작동해야합니다. 그러나 나는 그것을 시도 할 기회가 없었습니다.

가장 신뢰할 수있는 최고의 답변은 다음과 같습니다.

partprobe /dev/sdX

파티션 테이블 정보를 다시 읽는 것이 항상 작동하는 것은 아니지만 시도해보십시오.

hdparm -z /dev/sda

또는

sfdisk -R /dev/sda

작동하면 / proc / partitions의 값이 변경됩니다.

Centos7에서 :

https://access.redhat.com/solutions/199573 에 따르면

시도해야합니다 :

partx -u <partition>

그것은 나를 위해 일했다.

참고 : 실제로 편집중인 파티션이 열려 있거나 마운트되어 있거나 사용중인 것으로 가정하지 마십시오.

이 가정이 주어지면 파티션 테이블 을 성공적으로 다시 스캔 할 수 있으며 문제가 발생하지 않습니다. 해당 오류가 발생하면 파티션 테이블 이 현재 사용 중이므로 불일치가 발생하지 않으면 다시 스캔 할 수 없기 때문입니다.

편집중인 파티션을 기반으로하지 않습니다.

하나의 하드 디스크 ( /dev/sda)와 두 개의 파티션 ( /dev/sda1, /dev/sda2) 만 있고 하나의 파티션 ( /dev/sda1) 만 마운트 했다고 가정하십시오 . 마운트되지 않은 다른 파티션 ( /dev/sda2) 을 삭제하거나 변경 하면 파티션 테이블을 다시 읽지 못하고 커널이 이전 테이블을 사용한다는 오류가 발생합니다.

그러나 두 개의 하드 디스크 ( /dev/sda, /dev/sdb)가 있고 ( /dev/sdb) 의 파티션이 사용 중이 아닌 경우. 그런 다음 파티션을 추가 / 삭제 / 크기 조정 / 편집 /dev/sdb할 수 있으며 아무런 문제없이 다시 읽습니다. 그러나 변경 중에 / dev / sdb의 하나의 파티션이 마운트 된 경우에도 마찬가지입니다. 그런 다음 커널은 이전 테이블을 계속 사용합니다.

나는 (원래 질문자) 며칠 전에 다른 답변 ( partprobe /dev/sdX현재 허용되고 가장 투표가 높은 답변 포함)이 작동 하지 않은 상황이있었습니다 . 어떤 한 작업을하지만,이 있었다 :

blockdev --rereadpt /dev/sdX

(이것이 왜 효과가 있었는지, 다른 것들이 왜 효과가 없는지는 모르겠지만, 바쁜 서버에서 재부팅을 저장했기 때문에 제대로 작동했습니다.)

나는 centos 6.5 x64에 있습니다. 커널 2.6.32. fdisk 트릭을 테스트하여 크기를 조정하고 있습니다.

/dev/sda1 /boot
/dev/sda2 /

다음 명령은 모두 커널 다시 읽기 파티션을 만들지 않았습니다 .

• partprobe / dev / sda (경고 : 커널을 다시 읽지 못했습니다 ....)
• hdparm -z / dev / sda (BLKRRPART 실패 : 장치 또는 리소스 사용 중)
• blockdev -rereadpt / dev / sda (BLKRRPART 실패 : 장치 또는 자원 사용 중)
• sfdisk -R / dev / sda (BLKRRPART 실패 : 장치 또는 자원 사용 중)

여전히 작동하려면 재부팅이 필요합니다

모든 마운트 포인트가 마운트 해제 된 상태에서 Yocto 2.4를 실행하십시오.

partprobe /dev/sda 

장치에서 파티션을 삭제 한 후에도 여전히 파티션 테이블을 다시로드하지 못했습니다. 또한 시도했지만 실패했습니다.

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

모두 재부팅하라는 "BLKRRPART 실패 : 장치 또는 리소스 사용 중 ..."오류가보고되었습니다. udev가 이제 시스템 제어하에 있다는 사실 때문에 이전에 작동했던 방법의 실패일까요? 내가 시도한 그 라인을 따라 생각 :

systemctl restart systemd-udevd.service

그리고 갑자기 내 디스크를 다시 부팅하지 않고 다시 사용할 수 있습니다 !

다음과 같은 명령이 blockdev --rereadpt /dev/sdX실패 할 때

blockdev: ioctl error on BLKRRPART: Device or resource busy

이것은 일반적으로 일부 (오래된) 파티션이 여전히 커널에 의해 여전히 사용됨을 의미합니다.

가능한 원인 / 수정 :

1. sdX 파티션-예 sdX1-여전히 마운트되어 있습니다-확인 mount하고 마운트 해제하십시오
2. /dev/sdX1소프트웨어 급습의 일부입니다- cat /proc/mdstat예를 들어 관련 어레이를 확인 하고 중지하십시오.mdadm --stop /dev/md126
3. /dev/sdX1LVM 물리 볼륨의 일부입니다. pvdisplay/로 확인 vgdisplay하고 가능하면 비활성화하십시오vgchange
4. /dev/sdX1예를 통해 - 일부 장치 매핑의 일부입니다 cryptsetup- 확인 /dev/mapper하고 lsblk가능성이 매핑을 제거 (예를 들어 cryptsetup luksClose)
5. 일부 udev 프로빙으로 경쟁 조건-실행중인 프로세스 확인 ps및 프로세스 종료 가능

하나의 도구가있는 경우 - 말은 blockdev --rereadpt일반적으로 유사한 같은 것 (실패 partx -uv, kpartx, partprobe,을 kpartprobe) 근본 원인이 제거 될 때까지 유사한 방법으로 실패합니다.

시도해 볼 수도 있습니다 :

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

(그러나 작동하지 않습니다. 아래 주석을 참조하십시오)

kpartx -a <partition> 시스템을 재부팅하는 대신 새로 생성 된 파티션에서 두 번 실행할 수 있습니다.

udev 서비스가 실행 중인지 확인하십시오. partprobe, hdparm, blockdev 및 기타 다양한 명령이 / dev / 디렉토리에서 사용 가능한 장치 파일을 변경하지 않는 경우에 특히 유용합니다.

나를 위해 partprobe또는 blockdev솔루션이 작동 하지 않았습니다 . 그러나 이것은 작동합니다.

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

'man oracleasm-scandisks'에 대한 맨 페이지를 읽으면 아래 텍스트를 참고하십시오. oracleasm은 수행하는 모든 스캔의 소스로 / proc / partitions를 사용하고 있습니다. 디스크 검사를 수행하기 전에 / proc / partitions에 원시 장치가 나열되어 있어야합니다. / etc / sysconfig / oracleasm에있는 Scanorder 및 Scanexclude 매개 변수는 / proc / partitions (!!!!)에있는 이름과 관련이 있습니다.

---------- 남자 oracleasm-scandisks ------ ...

스캔 발생 방법 스캔은 네 가지 기본 단계로 진행됩니다.

   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.