อ่านตารางพาร์ติชั่นใหม่โดยไม่ต้องรีบู๊ต?

บางครั้งเมื่อปรับขนาดหรือลบล้างพาร์ติชันบนดิสก์ cfdisk จะพูดว่า:

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

(สิ่งนี้เกิดขึ้นกับเครื่องมือการแบ่งพาร์ติชันอื่น ๆ ด้วยดังนั้นฉันคิดว่านี่เป็นปัญหาของ Linux มากกว่าปัญหา cfdisk) เหตุใดจึงเป็นเช่นนี้และทำไมบางครั้งมันเกิดขึ้นเท่านั้นและฉันควรทำอย่างไรเพื่อหลีกเลี่ยงปัญหานี้

หมายเหตุ: โปรดสมมติว่าไม่มีพาร์ติชันที่ฉันกำลังแก้ไขเปิดอยู่ติดตั้งหรือใช้งานอยู่

ปรับปรุง:

cfdisk ใช้ioctl(fd, BLKRRPART, NULL)บอก Linux เพื่ออ่านตารางพาร์ติชันอีกครั้ง สองเครื่องมืออื่น ๆ ที่แนะนำจนถึง ( hdparm -z DEVICE, sfdisk -R DEVICE) ทำสิ่งเดียวกัน ในทางกลับกันpartprobe DEVICEคำสั่งดูเหมือนว่าจะใช้ ioctl ใหม่ที่เรียกว่า BLKPG ซึ่งอาจจะดีกว่า ฉันไม่รู้ (นอกจากนี้ยังกลับไปใช้ BLKRRPART หาก BLKPG ล้มเหลว)

BLKPG ดูเหมือนว่าเป็นการดำเนินการ "พาร์ติชันนี้มีการเปลี่ยนแปลงที่นี่คือขนาดใหม่" การดำเนินการและดูเหมือนpartprobeว่ามันจะเรียกว่าเป็นรายบุคคลในทุกพาร์ติชันบนอุปกรณ์ที่ผ่านไปดังนั้นมันควรจะทำงานถ้าพาร์ทิชันที่ไม่ได้ใช้ อย่างไรก็ตามฉันไม่ได้มีโอกาสลอง

IMHO คำตอบที่น่าเชื่อถือที่สุด / ที่ดีที่สุดคือ

partprobe /dev/sdX

การอ่านข้อมูลตารางพาร์ติชันใหม่ไม่ได้ผล แต่ลอง

hdparm -z /dev/sda

หรือ

sfdisk -R /dev/sda

หากใช้งานได้ค่าใน / proc / พาร์ทิชันจะเปลี่ยน

บน Centos7:

ตามhttps://access.redhat.com/solutions/199573

คุณควรลอง :

partx -u <partition>

มันใช้งานได้สำหรับฉัน

หมายเหตุ: โปรดสมมติว่าไม่มีพาร์ติชันที่ฉันกำลังแก้ไขเปิดอยู่ติดตั้งหรือใช้งานอยู่

จากสมมติฐานที่ว่าสามารถสร้างตารางพาร์ติชันใหม่ได้สำเร็จและปัญหาจะไม่เกิดขึ้น หากคุณได้รับข้อผิดพลาดนั่นอาจเป็นเพราะตารางพาร์ทิชันกำลังถูกใช้งานอยู่ดังนั้นจึงไม่สามารถสแกนซ้ำได้โดยไม่สร้างความไม่สอดคล้องกัน

มันไม่ได้ขึ้นอยู่กับพาร์ติชันที่คุณกำลังแก้ไข

สมมติว่าคุณมี harddisk ( /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 /

คำสั่งทั้งหมดต่อไปนี้ไม่ได้สร้างพาร์ติชันเคอร์เนล reread:

• 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 อยู่ภายใต้การควบคุมของ systemd หรือไม่? ฉันลองทำตามสิ่งเหล่านั้น

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/sdX1เป็นส่วนหนึ่งของปริมาณทางกายภาพ LVM - ตรวจสอบด้วย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 / directory

สำหรับฉันไม่ได้แก้ปัญหาpartprobeหรือblockdevทำงาน แม้ว่าอันนี้ใช้งานได้:

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

หากคุณอ่าน manpage สำหรับ 'man oracleasm-scandisks' คุณจะสังเกตข้อความด้านล่าง oracleasm ใช้ / proc / พาร์ติชั่นเป็นแหล่งที่มาของการสแกนทั้งหมดที่มันทำงาน คุณต้องรับอุปกรณ์ดิบของคุณอยู่ในรายการ / proc / พาร์ติชันก่อนจึงจะสามารถสแกนได้ พารามิเตอร์ Scanorder และ Scanexclude ที่คุณวางใน / etc / sysconfig / oracleasm เกี่ยวข้องกับชื่อที่พบใน / proc / พาร์ติชัน (!!!!)

---------- ผู้ชาย 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.