[parted-devel] some issues with ped_disk_commit_to_os()
dcantrell at redhat.com
Tue Sep 12 20:37:47 UTC 2006
Bart Hakvoort wrote:
>> Bart Hakvoort wrote:
>>> Hi people,
>>> As many of you probably know gparted uses libparted to create partitions
>>> and CLI tools to create filesystems on them. While this works quite well
>>> there has been a small problem since the beginning.
>>> Whenever i call ped_disk_commit_to_os() (which in turn will call
>>> fd, BLKRRPART) somewhere in the process) the devicenodes show up after a
>>> small delay. This delay causes the CLItools to throw a 'device not
>>> error every now and then. I've tried working with sync() and fsync(),
>>> without luck so far.
>>> Till now i simply 'solved' this by sleeping a bit after the reread, but
>>> this is not perfect and every now and then someone encounters this. Also
>>> wonder if there is a better way to solve this?
_kernel_reread_part_table() is called in libparted/arch/linux.c, which
calls the BLKRRPART ioctl.
To my knowledge, there is no better way or even any other way to get the
kernel to rescan the partition table. In doing that, the kernel will
register new partitions in sysfs. It's up to a user space process to
see those and create nodes in the /dev tree.
>> I've been running into this same thing for over a year in my work with the
>> Gentoo Installer. We are blaming udev. It seems like the device nodes are
>> created, destroyed, and then created again for some weird reason. I've had
>> where I commit to disk, check to make the /dev node exists, and then it's
>> when I call mkfs.foo or whatever on it.
> Yep, i have the same issues. You check if it exists, it actually does and
> when you try to use it, it's gone again ;)
This sounds like you're fighting with sysfs and/or udev.
>> In the installer, I've resorted to calling mkfs.foo in a loop a maximum of
>> times with a 1s delay after a failure. If the return value is zero, the
>> breaks and moves on. This obviously only works around the problem.
Yeah, not a spectacular solution.
>> The reason we blame udev is because we never saw this behavior when the
>> CDs used devfs.
devfs was certainly nicer for this case, but it had its share of problems.
> Ok, if noone on this list has an idea about what's going on, i propose we
> take this to some udev related list and see what we learn. It would be
> really nice if we were able to finally solve this.
> Any idea which list would be appropiate for this issue?
I'm not sure the udev people will care about this issue. The big reason
udev was created was to handle devices that users generally interact
with while the system is running. Things that need special permissions
set, or a sync program run (think PDAs, USB storage devices, game
It's unfortunate that everything was shoehorned in to udev because it
does not work well for things like block devices. It makes it difficult
for those of us who write installers! :)
0) Don't rely on udev, or for that matter, the node being created in
/dev for you. Move up a level and check for the device being registered
in sysfs (should also be available by looking at /proc/partitions...I
think that interface is still supported).
1) What we do in anaconda (RHEL and Fedora installer) is scan for block
devices on our own and make device nodes in /tmp after we see the device
register. We use those nodes during installation, but prepare files
like /etc/fstab for the udev world it will be rebooting in to.
Red Hat / Westford, MA
More information about the parted-devel