-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sat, Oct 14, 2017 at 05:42:39AM +0100, Andrew Clausen wrote: > Hi all, > > On 14 October 2017 at 01:20, Wojtek Porczyk <w...@invisiblethingslab.com> > wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > On Sat, Oct 14, 2017 at 02:06:43AM +0200, Wojtek Porczyk wrote: > > > On Sat, Oct 14, 2017 at 01:40:45AM +0200, Marek Marczykowski-Górecki > > wrote: > > > > On Sat, Oct 14, 2017 at 01:21:58AM +0200, Wojtek Porczyk wrote: > > > > > On Sat, Oct 14, 2017 at 01:20:13AM +0200, Marek Marczykowski-Górecki > > wrote: > > > > > > You can't reload partition table while it is used (something from > > there > > > > > > is mounted). At least Linux doesn't support it. > > > > > > > > > > Just tested with loop device, fdisk, and ext4. Looks like it works. > > Unless it > > > > > works only with loop? > > > > > > > > No, it doesn't work, at least not directly: > > > > > > > > (snip) > > > > > > The kernel still uses the old table. The new table will be used at > > the next reboot or after you run partprobe(8) or kpartx(8). > > > > > > > > I wonder on what conditions partprobe would work. And how would mounted > > > > filesystem react for it. > > > > > > I'm calling bullshit on that. Coredump follows: > > > > (...) > > > > > [root@qubes-dev tmp]# partprobe /dev/loop0 > > > [root@qubes-dev tmp]# echo $? > > > 0 > > > > (...) > > > > Look at strace of blockdev --rereadpt and partprobe. The difference is that > > blockdev (and I assume fdisk also, since both are from util-linux) fires > > ioctl(fd, BLKRRPART), but partprobe (from GNU parted) does something funny > > to > > /sys, which I didn't try to understand, but seems to work. > > > > My guess is that this is a missing feature in kernel, which parted works > > around. > > > > I am a Qubes user, and coincidentally, the original author of partprobe > (and parted). I haven't looked at partprobe/parted since 2005. The code > has changed a lot since then, but let me do my best... > > The BLKRRPART ioctl is no good because it can't accommodate busy block > devices at all, i.e. resizing partition 1 when partition 2 on the same disk > is mounted. > > Instead, Parted primarily uses the BLKPG family of ioctl to inform the > kernel of partition table changes. (It also has "new" support for the > device mapper -- but that's probably not relevant here.) You can read > about the BLKPG ioctl in /usr/include/linux/blkpg.h. Since 2012, the linux > kernel supports a new BLKPG feature to do online partition resizing, i.e. > telling the kernel to modify a mounted partition. I think this is what is > being used here. > > The relevant Parted code is in the function linux_disk_commit(), which > calls _disk_sync_part_table() and _blkpg_resize_partition() inside > http://git.savannah.gnu.org/cgit/parted.git/tree/libparted/arch/linux.c > > If the BLKPG ioctl fails, then partprobe/parted will throw an exception and > tell you about it.
Thanks for the explanation. This should be enough for the online resize part. Now, back to the main issue here: partition to resize isn't the last one, one need to move two other partitions first. Hmm, maybe parted can do that too? - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJZ4IF0AAoJENuP0xzK19csdS8H/1W/UsGDIIYtkOPr6tyvAYDM vXPK8MD9pO8EUaYz2iAUJHJyn2crmF0JNiU++ZtAKpxU9QlTc+ZPgJ/2br2NaWKU jJotIfgtEdJL6jOZjNhbZGb9gtQjalPx8fGj5CR2inxWvY1Q2Twj0yb/os4kdjSM OtJEft8l5jTfu0GUOaOleohv4VTebQOc6s4Ea1rJvDYBWvj/JE1bOkRoBkk4A2EE 1cGOHLTJpuIjJWhE5prO9DtVB5ppQHTsm2VFslgHdxtO3CorEPnGaltNOZoARffS yJRAr0FgxaT9KqMRTF0feZjs/DuYf9PzbfRvnBQKRc2p06ASzCLijgNBbgtlMVQ= =iMtL -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20171014133605.GR1059%40mail-itl. For more options, visit https://groups.google.com/d/optout.
