Hi Sage, On 17/12/2015 14:31, Sage Weil wrote: > On Thu, 17 Dec 2015, Loic Dachary wrote: >> Hi Ilya, >> >> This is another puzzling behavior (the log of all commands is at >> http://tracker.ceph.com/issues/14094#note-4). in a nutshell, after a >> series of sgdisk -i commands to examine various devices including >> /dev/sdc1, the /dev/sdc1 file disappears (and I think it will showup >> again although I don't have a definitive proof of this). >> >> It looks like a side effect of a previous partprobe command, the only >> command I can think of that removes / re-adds devices. I thought calling >> udevadm settle after running partprobe would be enough to ensure >> partprobe completed (and since it takes as much as 2mn30 to return, I >> would be shocked if it does not ;-). >> >> Any idea ? I desperately try to find a consistent behavior, something >> reliable that we could use to say : "wait for the partition table to be >> up to date in the kernel and all udev events generated by the partition >> table update to complete". > > I wonder if the underlying issue is that we shouldn't be calling udevadm > settle from something running from udev. Instead, of a udev-triggered > run of ceph-disk does something that changes the partitions, it > should just exit and let udevadm run ceph-disk again on the new > devices...? Unless I missed something this is on CentOS 7 and ceph-disk is only called from udev as ceph-disk trigger which does nothing else but asynchronously delegate the work to systemd. Therefore there is no udevadm settle from within udev (which would deadlock and timeout every time... I hope ;-). Cheers -- Loïc Dachary, Artisan Logiciel Libre
Attachment:
signature.asc
Description: OpenPGP digital signature
