Am Mon, 15 May 2017 17:58:48 -0700 schrieb Marc MERLIN <marc@xxxxxxxxxxx>: > On Mon, May 15, 2017 at 08:37:45PM +0200, Kai Krakow wrote: > > Am Mon, 15 May 2017 13:52:09 +0100 > > schrieb Nix <nix@xxxxxxxxxxxxx>: > > > > > On 14 May 2017, Kai Krakow said: > [...] > > > > > > udev does a blkid to see how the block device needs to be > > > activated: this relies on precisely the information wipefs > > > removes. Avoiding this problem is why wipefs *exists*. :) > > > > Yes, but something triggered udev when it shouldn't... > > > > This ends up in unregistering/stopping the bcache, then wipefs the > > cdev, then look if udev was triggered and eventually stop it again. > > > > I guess everytime I ran "fdisk -l" to double-check the devices, or > > "lsblk", or "blkid", udev was triggered and re-enabled the bcache. > > This is a race you cannot win. ;-) > > Note that this is orthogonal to the problem I reported. > It tells me > Already a bcache device on /dev/sde2, overwrite with --wipe-bcache > when it fact this does not work, apparently ever. > > So either the message gets changed, or > make-bcache --wipe-bcache > -C /dev/sde2 Device /dev/sde2 already has a non-bcache superblock, > remove it using wipefs and wipefs -a does not happen. there was no > non-bcache superblock. I look at both source codes of wipefs and make-bcache should give a clue. Since you made me curious, I'll probably take a look this weekend. -- Regards, Kai Replies to list-only preferred. -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
