[parted-devel] some issues with ped_disk_commit_to_os()

[David Cantrell]

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
>>> ioctl(int
>>> fd, BLKRRPART) somewhere in the process) the devicenodes show up after a
>>> small delay. This delay causes the CLItools to throw a 'device not
>>> found'
>>> error every now and then. I've tried working with sync() and fsync(),
>>> but
>>> 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
>>> i
>>> 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
>> cases
>> where I commit to disk, check to make the /dev node exists, and then it's
>> gone
>> 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
>> 10
>> times with a 1s delay after a failure. If the return value is zero, the
>> loop
>> 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
>> Gentoo
>> 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 
controllers).

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!  :)

My suggestions:

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.

-- 
David Cantrell
Red Hat / Westford, MA