From: Kai Krakow <hurikhan77@gmail.com>
To: linux-bcache@vger.kernel.org
Subject: Re: make-bcache bug?
Date: Sun, 14 May 2017 23:28:16 +0200 [thread overview]
Message-ID: <20170514232816.79c2530e@jupiter.sol.kaishome.de> (raw)
In-Reply-To: 20170514201940.76bu7rz764jeplnd@merlins.org
Am Sun, 14 May 2017 13:19:40 -0700
schrieb Marc MERLIN <marc@merlins.org>:
> On Sun, May 14, 2017 at 10:00:55PM +0200, Kai Krakow wrote:
> > Am Sun, 14 May 2017 10:58:40 -0700
> > schrieb Marc MERLIN <marc@merlins.org>:
> >
> > > bcache-tools (1.0.8-2+b1)
> > >
> > > gargamel:~# make-bcache -C /dev/sde2
> > > Already a bcache device on /dev/sde2, overwrite with --wipe-bcache
> > > gargamel:~# make-bcache --wipe-bcache -C /dev/sde2
> > > Device /dev/sde2 already has a non-bcache superblock, remove it
> > > using wipefs and wipefs -a
> > >
> > > /dev/sde2 is an old bcache I'm reformatting.
> > > The first message is correct
> > > The 2nd one is not "/dev/sde2 already has a non-bcache superblock"
> > >
> > > Clearly it can't have a bcache and not a bcache superblock,
> > > right?
> >
> > I don't think that each filesystem puts their superblocks in the
> > same position. Plus, there are usually backup superblocks across
> > the area.
> >
> > So you may well see both warnings and both are correct.
> >
> > Use wipefs, there seems to be an orphan superblock.
>
> Doesn't wipefs -a clear just 16 bytes or so?
> I did it and it fixed my problem, but this block device was a bcache
> before, and of course on top of that bcache I then added a filesystem.
>
> Let's test this.
> 1) I wipefs'ed it
> 2) I made a new cache device on top
> 3) I did not put a filesystem or use it, because registration is
> broken and still rquires a reboot
> bcache: register_cache() error opening sde2: cache_alloc(): -ENOMEM
> bcache: register_bcache() error opening /dev/sde2: (null)
>
> 4) recreating a new cache on top fo the unused cache, fails again.
> Basically the superblock detection is not working right and detects
> bcache as a non bcache superblock.
>
> gargamel:/mnt/btrfs_pool2# make-bcache -C /dev/sde2
> Already a bcache device on /dev/sde2, overwrite with --wipe-bcache
> gargamel:/mnt/btrfs_pool2# make-bcache --wipe-bcache -C /dev/sde2
> Device /dev/sde2 already has a non-bcache superblock, remove it using
> wipefs and wipefs -a
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.
If you get udev not to interfere with such actions, you usually also do
not need to reboot because unregistration and registration works.
But you can also easily get stuck when you decompose the bcache device
in the wrong way. It will simply stay registered then and cannot be
unregistered because the device is still in use. In that situation I
wouldn't wipefs the device.
--
Regards,
Kai
Replies to list-only preferred.
next prev parent reply other threads:[~2017-05-14 21:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-14 17:58 make-bcache bug? Marc MERLIN
2017-05-14 18:01 ` Marc MERLIN
2017-05-14 18:12 ` Still have a problem registering cache devices without rebooting :( Marc MERLIN
2017-05-14 20:00 ` make-bcache bug? Kai Krakow
2017-05-14 20:19 ` Marc MERLIN
2017-05-14 21:28 ` Kai Krakow [this message]
2017-05-15 12:52 ` Nix
2017-05-15 18:37 ` Kai Krakow
2017-05-16 0:58 ` Marc MERLIN
2017-05-16 2:02 ` Kai Krakow
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170514232816.79c2530e@jupiter.sol.kaishome.de \
--to=hurikhan77@gmail.com \
--cc=linux-bcache@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox