Bug 1000817 - Allow bcache devices to be used as PVs by default
Summary: Allow bcache devices to be used as PVs by default
Alias: None
Product: Fedora
Classification: Fedora
Component: lvm2
Version: 20
Hardware: All
OS: All
Target Milestone: ---
Assignee: Alasdair Kergon
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 998543 1008227 1008228
TreeView+ depends on / blocked
Reported: 2013-08-25 15:48 UTC by Rolf Fokkens
Modified: 2013-09-26 06:17 UTC (History)
13 users (show)

Fixed In Version: lvm2-2.02.102-1.fc20
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2013-09-26 06:17:34 UTC
Type: Bug

Attachments (Terms of Use)
LVM patch to accept bcache as a PV (344 bytes, patch)
2013-09-13 21:08 UTC, Rolf Fokkens
no flags Details | Diff

Description Rolf Fokkens 2013-08-25 15:48:05 UTC
Description of problem: The planned SSD cache support for Fedora 20 may be hindered by the fact that LVM2 does not accept /dev/bcache* devices as physical volumes.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Use F19 on a PC with an SSD
2. Create a bcache device /dev/bcache0 using bcache-tools
3. Do pvcreate /dev/bcache0

Actual results:
# pvcreate /dev/bcache0
Device /dev/bcache0 not found (or ignored by filtering).

Expected results:
Successful pvcreate

Additional info:

Comment 1 Rolf Fokkens 2013-08-25 15:51:35 UTC
A workaround is to have the user add 

    types = [ "bcache", 16 ]

in /etc/lvm/lvm.conf 

I consider it a workaround, since I think the solution would be to have LVM2 accept bcache in /lib/filters/filter.c

Comment 2 Ric Wheeler 2013-08-25 20:26:41 UTC
Note that DM has a dm-cache target that is a caching device (no need for BCACHE).

BCACHE and dm-cache are designed for different workloads, so performance will not be the same for every workload.

Comment 3 Alasdair Kergon 2013-08-26 00:23:11 UTC
Please provide a reference for your choice of 16 rather than 1.

Comment 4 Rolf Fokkens 2013-08-26 07:12:27 UTC
I'm not sure what "the maximum number of partitions" means, but I guess you're right, it should be 1.

From http://bcache.evilpiepirate.org/Design/

"When bcache loads, it creates a major device type. Every slow storage device registered with bcache creates a new minor device number that is associated with that storage device."

Hope that provides the right information.

Comment 5 Alasdair Kergon 2013-08-26 08:37:30 UTC
Just like on other similar bugzillas, create two devices and provide the /proc/devices output and their major/minor numbers.

Comment 6 Rolf Fokkens 2013-08-26 09:02:21 UTC
[root@localhost ~]# cat /proc/devices 
Character devices:
Block devices:
259 blkext
  7 loop
135 sd
252 bcache
253 device-mapper
254 mdp
[root@localhost ~]# cat /proc/partitions 
major minor  #blocks  name

   8        0   20971520 sda
   8        1     512000 sda1
   8        2   12356608 sda2
   8        3    8101888 sda3
   8       32   20971520 sdc
   8       33   20970496 sdc1
   8       16    2097152 sdb
   8       17    2096128 sdb1
   8       48    2097152 sdd
   8       49    2096128 sdd1
 253        0   10240000 dm-0
 253        1    2113536 dm-1
 252        0    8101880 bcache0
 253        2    4194304 dm-2
 252        1   20970488 bcache1
[root@localhost ~]# ls -l /dev/bcache*
brw-rw----. 1 root disk 252, 0 Aug 26 10:52 /dev/bcache0
brw-rw----. 1 root disk 252, 1 Aug 26 10:55 /dev/bcache1
[root@localhost ~]#

Comment 7 Rolf Fokkens 2013-09-06 05:30:13 UTC
Towards the planning of F20 having this implemented would be really nice. Is there an indication when this will be implemented?

Comment 8 Rolf Fokkens 2013-09-12 20:20:35 UTC
Could anybody please respond?

Comment 9 Mike Snitzer 2013-09-12 23:22:29 UTC
(In reply to Rolf Fokkens from comment #8)
> Could anybody please respond?

This isn't a difficult change to lvm2, but it certainly isn't a priority given bcache isn't a priority.  Have you looked at the lvm2 code in this area?

Seems to me you're looking to stand up bcache without the ability to properly support it.  This seems short-cited.

I can appreciate that you just want a functional caching layer in fedora but if you have to completely rely on other developers to make it work and/or supportable then you'll just have problems down the road.  Especially if the upstream bcache developer (Kent) isn't actively working with fedora to make it fully supported.  Red Hat is not is a position to support bcache at this time.

Comment 10 Rolf Fokkens 2013-09-13 05:24:55 UTC
Thanks for the response.

My effort in making bcache work has started since the SSD cache change was accepted: https://fedorahosted.org/fesco/ticket/1145. In that process the relation
with Kent Overstreet was not identified as a blocking issue.

So to me it's now unclear how to move forward. Can I be of any help?

If I make a patch, do you consider accepting that?

Comment 11 Rolf Fokkens 2013-09-13 08:51:57 UTC
I'll do some testing later, but this should be it:

--- LVM2.2.02.98/lib/filters/device-types.h.orig	2013-09-13 10:40:28.270907244 +0200
+++ LVM2.2.02.98/lib/filters/device-types.h	2013-09-13 10:42:51.760734860 +0200
@@ -56,5 +56,6 @@
 	{"blkext", 1},		/* Extended device partitions */
 	{"fio", 16},		/* Fusion */
 	{"mtip32xx", 16},	/* Micron PCIe SSDs */
+	{"bcache", 1},		/* Bcache disk */
 	{"", 0}

Comment 12 Rolf Fokkens 2013-09-13 21:08:20 UTC
Created attachment 797540 [details]
LVM patch to accept bcache as a PV

After a small correction the patch applied fine to f20 LVM:

--- LVM2.2.02.99/lib/device/device-types.h.orig	2013-09-13 21:51:31.594728463 +0200
+++ LVM2.2.02.99/lib/device/device-types.h	2013-09-13 21:52:34.640634634 +0200
@@ -60,5 +60,6 @@
 	{"vtms", 16, "Violin Memory"},
 	{"skd", 16, "STEC"},
 	{"scm", 8, "Storage Class Memory (IBM S/390)"},
+	{"bcache", 1, "bcache cached disk"},
 	{"", 0, ""}

Testing showed that this patch fixes the issue; no more tweaks in lvm.conf are needed.

Comment 13 Alasdair Kergon 2013-09-16 15:20:35 UTC
This is NOT the same as adding recognition for new types of hardware: bcache creates a sophisticated type of block device that must be tested thoroughly in combination with device-mapper/lvm and should not be assumed to work correctly in all circumstances yet.

I shall add the recognition as requested here because there is an expectation upstream that it needs to work.  This should NOT be taken to imply that the combination of device-mapper over bcache has already been tested thoroughly and shown to work.  If any problems are found they should be reported on the appropriate mailing lists ( dm-devel / linux-kernel / lvm-devel / linux-bcache ) so they can be investigated and fixed.

Comment 15 Rolf Fokkens 2013-09-16 17:21:35 UTC
Thanks, this is great!

I completeley agree with you, and will position bcache experimental on every occasion.

Comment 16 Alasdair Kergon 2013-09-23 15:07:47 UTC
In release 2.02.102.  Should be building packages in next couple of days.

Comment 17 Alasdair Kergon 2013-09-23 15:10:01 UTC
This release also contains a new 'lvm devtypes' command that lists the built-in supported block device types.

Comment 18 Fedora Update System 2013-09-24 08:47:53 UTC
lvm2-2.02.102-1.fc20 has been submitted as an update for Fedora 20.

Comment 19 Fedora Update System 2013-09-24 22:52:22 UTC
Package lvm2-2.02.102-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing lvm2-2.02.102-1.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 20 Fedora Update System 2013-09-26 06:17:34 UTC
lvm2-2.02.102-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.