From mboxrd@z Thu Jan 1 00:00:00 1970 From: Loic Dachary Subject: Re: puzzling disapearance of /dev/sdc1 Date: Thu, 17 Dec 2015 15:10:32 +0100 Message-ID: <5672C258.1020700@dachary.org> References: <5672AAD7.8030004@dachary.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TTJavLRg9sqvt6kTGUFBUWRaJ1xCuEDHX" Return-path: Received: from mail2.dachary.org ([91.121.57.175]:51962 "EHLO smtp.dmail.dachary.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S934720AbbLQOKi (ORCPT ); Thu, 17 Dec 2015 09:10:38 -0500 In-Reply-To: Sender: ceph-devel-owner@vger.kernel.org List-ID: To: Sage Weil Cc: Ilya Dryomov , Ceph Development This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TTJavLRg9sqvt6kTGUFBUWRaJ1xCuEDHX Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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=20 >> http://tracker.ceph.com/issues/14094#note-4). in a nutshell, after a=20 >> series of sgdisk -i commands to examine various devices including=20 >> /dev/sdc1, the /dev/sdc1 file disappears (and I think it will showup=20 >> 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 calli= ng=20 >> udevadm settle after running partprobe would be enough to ensure=20 >> 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 b= e=20 >> up to date in the kernel and all udev events generated by the partitio= n=20 >> table update to complete". >=20 > I wonder if the underlying issue is that we shouldn't be calling udevad= m=20 > settle from something running from udev. Instead, of a udev-triggered = > run of ceph-disk does something that changes the partitions, it=20 > should just exit and let udevadm run ceph-disk again on the new=20 > devices...? Unless I missed something this is on CentOS 7 and ceph-disk is only calle= d from udev as ceph-disk trigger which does nothing else but asynchronous= ly delegate the work to systemd. Therefore there is no udevadm settle fro= m within udev (which would deadlock and timeout every time... I hope ;-).= Cheers --=20 Lo=EFc Dachary, Artisan Logiciel Libre --TTJavLRg9sqvt6kTGUFBUWRaJ1xCuEDHX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlZywlgACgkQ8dLMyEl6F22oGwCfVcBdq8j4NxPX5fltgworA8mx QloAn28UfbWrMNfPB0l5zembyZQypiKX =2+VP -----END PGP SIGNATURE----- --TTJavLRg9sqvt6kTGUFBUWRaJ1xCuEDHX--