linux-bcache.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rolf Fokkens <rolf@rolffokkens.nl>
To: Ian Pilcher <arequipeno@gmail.com>, linux-bcache@vger.kernel.org
Subject: Re: "device busy" error when registering device
Date: Wed, 13 Aug 2014 22:24:33 +0200	[thread overview]
Message-ID: <53EBC981.1000303@rolffokkens.nl> (raw)
In-Reply-To: <lqcd46$hvl$1@ger.gmane.org>

Hi Ian,

Sorry for the late response. Due to holidays it escaped my attention.

I'm running a very similar setup, but my system boots 100% of the time. 
So it may be useful to find out what's causing the problems at your 
system. You're using Intel RAID and I'm using Linux software RAID. It 
may be relevant, I don't know.

These are the details of my system, maybe you can spot a significant 
difference:

[root@home07 ~]# cat /proc/version
Linux version 3.15.6-200.fc20.x86_64 
(mockbuild@bkernel02.phx2.fedoraproject.org) (gcc version 4.8.3 20140624 
(Red Hat 4.8.3-1) (GCC) ) #1 SMP Fri Jul 18 02:36:27 UTC 2014
[root@home07 ~]#
Filesystem                 Size  Used Avail Use% Mounted on
/dev/mapper/BCACHE-ROOTFS   79G   56G   20G  75% /
devtmpfs                   3.9G     0  3.9G   0% /dev
tmpfs                      3.9G  212K  3.9G   1% /dev/shm
tmpfs                      3.9G  9.2M  3.9G   1% /run
tmpfs                      3.9G     0  3.9G   0% /sys/fs/cgroup
tmpfs                      3.9G  888K  3.9G   1% /tmp
/dev/md0                   462M  383M   56M  88% /boot
[root@home07 ~]# vgdisplay
   --- Volume group ---
   VG Name               BCACHE
   System ID
   Format                lvm2
   Metadata Areas        1
   Metadata Sequence No  18
   VG Access             read/write
   VG Status             resizable
   MAX LV                0
   Cur LV                3
   Open LV               2
   Max PV                0
   Cur PV                1
   Act PV                1
   VG Size               139.91 GiB
   PE Size               4.00 MiB
   Total PE              35816
   Alloc PE / Size       35328 / 138.00 GiB
   Free  PE / Size       488 / 1.91 GiB
   VG UUID               jIxLKK-ASqT-hlHy-D87m-lVLu-TFFc-7Tncp6

[root@home07 ~]# pvdisplay
   --- Physical volume ---
   PV Name               /dev/bcache0
   VG Name               BCACHE
   PV Size               139.91 GiB / not usable 2.87 MiB
   Allocatable           yes
   PE Size               4.00 MiB
   Total PE              35816
   Free PE               488
   Allocated PE          35328
   PV UUID               McXfNf-PEn1-DFEl-pAsX-3aIz-C2y6-xf75QV
[root@home07 ~]# bcache-status -s
--- bcache ---
UUID                        bc9e13cb-b50d-4016-bb52-1e20390ce248
Block Size                  512 B
Bucket Size                 512.00 KiB
Congested?                  False
Read Congestion             0.0ms
Write Congestion            0.0ms
Total Cache Size            30 GiB
Total Cache Used            23 GiB    (77%)
Total Cache Unused          7 GiB    (23%)
Evictable Cache             28 GiB    (94%)
Replacement Policy          [lru] fifo random
Cache Mode                  writethrough [writeback] writearound none
Total Hits                  155910    (95%)
Total Misses                7204
Total Bypass Hits           5230    (100%)
Total Bypass Misses         0
Total Bypassed              4.0 MiB
--- Backing Device ---
   Device File               /dev/md2 (9:2)
   bcache Device File        /dev/bcache0 (252:0)
   Size                      140 GiB
   Cache Mode                writethrough [writeback] writearound none
   Readahead                 0
   Sequential Cutoff         0 B
   Merge sequential?         False
   State                     dirty
   Writeback?                True
   Dirty Data                2 GiB
   Total Hits                155910    (95%)
   Total Misses              7204
   Total Bypass Hits         5230    (100%)
   Total Bypass Misses       0
   Total Bypassed            4.0 MiB
--- Cache Device ---
   Device File               /dev/sdd1 (8:49)
   Size                      30 GiB
   Block Size                512 B
   Bucket Size               512.00 KiB
   Replacement Policy        [lru] fifo random
   Discard?                  False
   I/O Errors                0
   Metadata Written          43.9 MiB
   Data Written              4 GiB
   Buckets                   61440
   Cache Used                23 GiB    (77%)
   Cache Unused              7 GiB    (23%)
[root@home07 ~]# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md1 : active raid5 sdc3[0] sda3[1] sdb3[2]
       1027968 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]

md0 : active raid1 sdc1[0] sda1[1] sdb1[2]
       496896 blocks [3/3] [UUU]

md2 : active raid5 sda5[1] sdc5[0] sdb5[2]
       146705280 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>
[root@home07 ~]#

sda, sdb and sdc are SAMSUNG HD160JJ disks
sdd is a SanDisk SDSSDP06

The following may also be relevant, your device may be loked due to 
misidentification:

[root@home07 ~]# for i in /dev/sd[abc]1 /dev/sd[abc]3 /dev/md2 /dev/sdd1 
/dev/bcache0 ; do echo $i; wipefs "$i" | sed 's/^/   /'; done
/dev/sda1
    offset               type
----------------------------------------------------------------
    0x438                ext3   [filesystem]
                         LABEL: BOOT
                         UUID: a3768dfd-37ec-45d1-a01b-76280ed390d0

    0x1e540000           linux_raid_member   [raid]
                         UUID: b7036aaf-3c8d-e714-bfe7-8010bc810f04

/dev/sdb1
    offset               type
----------------------------------------------------------------
    0x438                ext3   [filesystem]
                         LABEL: BOOT
                         UUID: a3768dfd-37ec-45d1-a01b-76280ed390d0

    0x1e540000           linux_raid_member   [raid]
                         UUID: b7036aaf-3c8d-e714-bfe7-8010bc810f04

/dev/sdc1
    offset               type
----------------------------------------------------------------
    0x438                ext3   [filesystem]
                         LABEL: BOOT
                         UUID: a3768dfd-37ec-45d1-a01b-76280ed390d0

    0x1e540000           linux_raid_member   [raid]
                         UUID: b7036aaf-3c8d-e714-bfe7-8010bc810f04

/dev/sda3
    offset               type
----------------------------------------------------------------
    0x1f5f0000           linux_raid_member   [raid]
                         UUID: 59d3d229-892d-7dae-e109-537ecd2580d5

/dev/sdb3
    offset               type
----------------------------------------------------------------
    0x218                LVM2_member   [raid]
                         UUID: 12Zw7I-EFzj-hX5g-MXyM-0LTu-rg9d-vi25QE

    0x1f5f0000           linux_raid_member   [raid]
                         UUID: 59d3d229-892d-7dae-e109-537ecd2580d5

/dev/sdc3
    offset               type
----------------------------------------------------------------
    0x218                LVM2_member   [raid]
                         UUID: 12Zw7I-EFzj-hX5g-MXyM-0LTu-rg9d-vi25QE

    0x1f5f0000           linux_raid_member   [raid]
                         UUID: 59d3d229-892d-7dae-e109-537ecd2580d5

/dev/md2
    offset               type
----------------------------------------------------------------
    0x1018               bcache   [other]
                         UUID: 63aef7ae-d550-4ca6-8063-0b7d0cd63ad5

/dev/sdd1
    offset               type
----------------------------------------------------------------
    0x1018               bcache   [other]
                         UUID: 0d553929-3ef5-4f65-8479-2868bbba7329

/dev/bcache0
    offset               type
----------------------------------------------------------------
    0x218                LVM2_member   [raid]
                         UUID: McXfNf-PEn1-DFEl-pAsX-3aIz-C2y6-xf75QV

[root@home07 ~]#


Note the single (bcache) signature on md2.Check if your md126p2 RAID 
device also has single signature.

Also note the double signatures on sdb3 and sdc3. I wasn't aware of 
this, these double signatures might get me into trouble if LVM would 
claim them before linux raid. But I've been lucky apparently.

Rolf

On 07/19/2014 02:11 AM, Ian Pilcher wrote:
> I just finished moving my existing Fedora 20 root filesystem onto a
> bcache device (actually LVM on top of a bcache physical volume).
>
> The bcache cache device is /dev/sda2, a partition on my SSD; the backing
> device is /dev/md126p5, a partition on an Intel RAID (imsm) volume.
>
> This configuration only boots successfully about 50% of the time.  The
> other 50% of the time, the bcache device is not created, and dracut
> times out and dumps me into an emergency shell.
>
> After changing the bcache-register script to use /sys/fs/bcache/register
> (instead of register_quiet), I see a "device busy" error when udev
> attempts to register the backing device:
>
>    [    2.105581] bcache: register_bcache() error opening /dev/md126p5:
> device busy
>
> This is kernel 3.5.15, so this doesn't mean that the device is already
> registered; something else has it (temporarily) opened.  I say that it's
> opened temporarily, because I am able to register the backing device
> manually from the dracut shell -- which starts the the bcache device.
>
> Looking at /usr/lib/udev/bcache-register and the bcache_register source
> in drivers/md/bcache/super.c, I notice 2 things.
>
> (1) bcache-register gives up immediately when an error occurs because of
>      a (possibly temporary) conflict.
>
> (2) Although the driver logs a different message in the already
>      registered case ("device already registered" instead of "device
>      busy"), it doesn't provide userspace with any way to distinguish the
>      two cases; it always returns -EINVAL.
>
> Suggested fix:
>
> (1) Change bcache_register to return -EBUSY in the device busy case
>      (while still returning -EINVAL in the already registered case).
>
> (2) Change bcache-register to check the exit code of the registration
>      attempt and retry in the EBUSY case.
>
> Does this make sense?
>

  parent reply	other threads:[~2014-08-13 20:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-19  0:11 "device busy" error when registering device Ian Pilcher
2014-07-19  7:23 ` Josep Lladonosa
2014-07-22  4:46   ` Ian Pilcher
2014-07-22  5:13 ` RFC: Handle "device busy" error when registering Ian Pilcher
2014-07-23  3:43   ` Ian Pilcher
2014-08-13 20:24 ` Rolf Fokkens [this message]
2014-08-20  1:38   ` "device busy" error when registering device Ian Pilcher
2014-09-06  7:34     ` Rolf Fokkens

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=53EBC981.1000303@rolffokkens.nl \
    --to=rolf@rolffokkens.nl \
    --cc=arequipeno@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;
as well as URLs for NNTP newsgroup(s).