public inbox for linux-bcache@vger.kernel.org
 help / color / mirror / Atom feed
From: Stefan Priebe - Profihost AG <s.priebe@profihost.ag>
To: Michael Lyle <mlyle@lyle.org>
Cc: Coly Li <i@coly.li>,
	"linux-bcache@vger.kernel.org" <linux-bcache@vger.kernel.org>,
	n.fahldieck@profihost.ag
Subject: Re: ont out of 6 bcache devices does not register automatically
Date: Tue, 28 Nov 2017 20:32:25 +0100	[thread overview]
Message-ID: <ce696f9d-07e5-88b4-dca8-dbef47594fca@profihost.ag> (raw)
In-Reply-To: <CAJ+L6qc79S1t10WfeycRFLesuqbZNfUXrN7qo6fVuwbHk=n8xw@mail.gmail.com>


Am 28.11.2017 um 17:05 schrieb Michael Lyle:
> I don't know.  I don't maintain your userland nor do I know the possible
> implications in your environment.

nobody asked for this - but bcache provides bcache-tools and upstream
udev rules and those don't work in this case. To i consider this an
upstream bug. Not a bug in my envorinment or in my distribution.

I can fix this myself - i just had the hope to get it fixed upstream so
others don't fall into the same issue.

Greets,
Stefan

> Mike
> 
> On Tue, Nov 28, 2017 at 1:36 AM, Stefan Priebe - Profihost AG
> <s.priebe@profihost.ag <mailto:s.priebe@profihost.ag>> wrote:
> 
>     ping - nobody? Ideas?
> 
>     Am 23.11.2017 um 08:10 schrieb Stefan Priebe - Profihost AG:
>     > Hello,
>     >
>     > i got it...
>     >
>     > first of all the same issue still applies to util-linux v2.31 which is
>     > the latest upstream version.
>     >
>     > # ./blkid --version
>     > lt-blkid from util-linux 2.31  (libblkid 2.31.0, 19-Oct-2017)
>     >
>     > # ./blkid -o udev -p /dev/sdf1
>     > ID_FS_AMBIVALENT=other:bcache other:xfs_external_log
>     >
>     > The issue is somewhat different. The device is used for ceph which
>     > stores on on that Disk 4MB slices of VM block devices.
>     >
>     > So we have:
>     > bcache => XFS on top => thousands of files containing VM images => XFS
>     > in those images
>     >
>     > So the xfs_external_log superblock which is seen by blkid is in
>     reality
>     > a superblock of a VM image inside a file which is saved in bcache.
>     >
>     > This make even more sense as the system was bootable without any
>     > problems for the last few years without swapping a disk. But somewhat
>     > now a VM image file has exactly positioned it's superblock on a
>     position
>     > blkid expects a superblock.
>     >
>     > I see no way to solve it except for changing the udev rules file which
>     > comes with bcache-tools.
>     >
>     > Instead of only checking:
>     > ENV{ID_FS_TYPE}=="bcache", GOTO="bcache_backing_found"
>     >
>     > it also needs to check for:
>     > ID_FS_AMBIVALENT=other:bcache
>     >
>     > Any opinions or suggestions?
>     >
>     > Greets,
>     > Stefan
>     >
>     > Am 22.11.2017 um 22:13 schrieb Stefan Priebe - Profihost AG:
>     >>
>     >> Am 22.11.2017 um 22:10 schrieb Michael Lyle:
>     >>> On 11/22/2017 01:07 PM, Stefan Priebe - Profihost AG wrote:
>     >>>> default debian jessie version:
>     >>>> # blkid -v
>     >>>> blkid from util-linux 2.25.2  (libblkid 2.25.0, 24-Oct-2014)
>     >>>
>     >>> OK, so it's ancient.
>     >>>
>     >>> One other thing that can get you-- if there was ever an xfs or other
>     >>> filesystem on this disk -without- bcache, then you created
>     bcache & xfs
>     >>> on it without wipefs... the old superblock can still be hanging
>     around
>     >>> and not having happened to been rewritten.
>     >>
>     >> no there shouldn't eb ever an xfs without it on disk - but i can't
>     >> guarantee that.
>     >>
>     >> To reproduce the isue you need the first 10MB of the disk.
>     >>
>     >> See below:
>     >>
>     >> Still ok:
>     >>
>     >> # dd if=/dev/sdf1 of=/tmp/8k bs=8M count=1
>     >> 1+0 records in
>     >> 1+0 records out
>     >> 8388608 bytes (8,4 MB) copied, 0,01318 s, 636 MB/s
>     >> # /sbin/blkid -o udev -p /tmp/8k
>     >> ID_FS_UUID=65811163-4ffc-4823-ad72-bae10ce85b63
>     >> ID_FS_UUID_ENC=65811163-4ffc-4823-ad72-bae10ce85b63
>     >> ID_FS_TYPE=bcache
>     >> ID_FS_USAGE=other
>     >>
>     >> not anymore:
>     >>
>     >> # dd if=/dev/sdf1 of=/tmp/8k bs=10M count=1
>     >> 1+0 records in
>     >> 1+0 records out
>     >> 10485760 bytes (10 MB) copied, 0,0115798 s, 906 MB/s
>     >> # /sbin/blkid -o udev -p /tmp/8k
>     >> ID_FS_AMBIVALENT=other:bcache other:xfs_external_log
>     >>
>     >> Stefan
>     >>
>     >>>
>     >>> Mike
>     >>>
>     >>>>
>     >>>>>
>     >>>>> Mike
>     >>>>> --
>     >>>>> To unsubscribe from this list: send the line "unsubscribe
>     linux-bcache" in
>     >>>>> the body of a message to majordomo@vger.kernel.org
>     <mailto:majordomo@vger.kernel.org>
>     >>>>> More majordomo info at 
>     http://vger.kernel.org/majordomo-info.html
>     <http://vger.kernel.org/majordomo-info.html>
>     >>>>>
>     >>>> --
>     >>>> To unsubscribe from this list: send the line "unsubscribe
>     linux-bcache" in
>     >>>> the body of a message to majordomo@vger.kernel.org
>     <mailto:majordomo@vger.kernel.org>
>     >>>> More majordomo info at 
>     http://vger.kernel.org/majordomo-info.html
>     <http://vger.kernel.org/majordomo-info.html>
>     >>>>
>     >>>
> 
> 

  parent reply	other threads:[~2017-11-28 19:32 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-22 11:23 ont out of 6 bcache devices does not register automatically Stefan Priebe - Profihost AG
2017-11-22 12:16 ` Coly Li
2017-11-22 12:26   ` Stefan Priebe - Profihost AG
2017-11-22 12:57     ` Coly Li
2017-11-22 13:14       ` Stefan Priebe - Profihost AG
2017-11-22 13:29         ` Coly Li
2017-11-22 14:16           ` Stefan Priebe - Profihost AG
2017-11-22 15:51             ` Coly Li
2017-11-22 19:07               ` Stefan Priebe - Profihost AG
2017-11-22 17:51         ` Michael Lyle
2017-11-22 19:06           ` Stefan Priebe - Profihost AG
2017-11-22 19:42             ` Stefan Priebe - Profihost AG
2017-11-22 20:22               ` Michael Lyle
2017-11-22 20:36                 ` Stefan Priebe - Profihost AG
2017-11-22 20:44                   ` Michael Lyle
2017-11-22 20:56                     ` Stefan Priebe - Profihost AG
2017-11-22 21:03                       ` Michael Lyle
2017-11-22 21:07                         ` Stefan Priebe - Profihost AG
2017-11-22 21:10                           ` Michael Lyle
2017-11-22 21:13                             ` Stefan Priebe - Profihost AG
2017-11-23  7:10                               ` Stefan Priebe - Profihost AG
2017-11-28  9:36                                 ` Stefan Priebe - Profihost AG
     [not found]                                   ` <CAJ+L6qc79S1t10WfeycRFLesuqbZNfUXrN7qo6fVuwbHk=n8xw@mail.gmail.com>
2017-11-28 19:32                                     ` Stefan Priebe - Profihost AG [this message]
2017-11-28 19:51                                       ` Michael Lyle
2017-11-28 19:59                                         ` Stefan Priebe - Profihost AG
2017-11-28 20:05                                           ` Michael Lyle
2017-11-28 20:31                                             ` Stefan Priebe - Profihost AG
2017-12-01 15:10                                               ` Nix
2017-12-10 19:34                                                 ` Stefan Priebe - Profihost AG
2017-12-10 19:36                                                   ` Michael Lyle
2017-12-10 19:39                                                     ` Stefan Priebe - Profihost AG
2017-12-12 15:38                                                     ` Nix
2017-11-22 21:10                         ` Stefan Priebe - Profihost AG
2017-11-22 21:13                           ` Michael Lyle
2017-11-23 11:43               ` Kai Krakow
2017-11-23 12:03                 ` Stefan Priebe - Profihost AG

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=ce696f9d-07e5-88b4-dca8-dbef47594fca@profihost.ag \
    --to=s.priebe@profihost.ag \
    --cc=i@coly.li \
    --cc=linux-bcache@vger.kernel.org \
    --cc=mlyle@lyle.org \
    --cc=n.fahldieck@profihost.ag \
    /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