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:
> > > I had done this previously, too, and had no such message. But I had
> > > to use wipefs anyway because otherwise udev came and triggered the
> > > device for reasons I couldn't really follow.
> >
> > 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.
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/
--
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
