All of lore.kernel.org
 help / color / mirror / Atom feed
* Fwd: bcache and dm targets (specifically lvm)
       [not found] ` <CAOzFzEjKapphA5NKCWbEyx4nvjWw+e_dxr+fOLr8f5j586jiyA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2012-03-02  5:49   ` Joseph Glanville
       [not found]     ` <CAOzFzEjffLGjYhOznTo1F3moHLq+nvKYZFoy7mkU-q8RPDd9oQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 16+ messages in thread
From: Joseph Glanville @ 2012-03-02  5:49 UTC (permalink / raw)
  To: linux-bcache-u79uwXL29TY76Z2rM5mHXA

Hi,

I can't use bcache devices as members of lvm volume groups because
dmsetup can't find the devices.
It provides the ever useful feedback of:
# pvcreate /dev/bcache0
  Device /dev/bcache0 not found (or ignored by filtering).

My LVM.conf is only filtering out nbd devices:
filter = [ "r|/dev/nbd.*|", "a/.*/" ]

Any insight would be greatly appreciated. :)

I also noted that bcache devices don't appear in iostat..

Joseph.

--
Founder | Director | VP Research
Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
99 52 | Mobile: 0428 754 846


-- 
Founder | Director | VP Research
Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
99 52 | Mobile: 0428 754 846

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: bcache and dm targets (specifically lvm)
       [not found]     ` <CAOzFzEjffLGjYhOznTo1F3moHLq+nvKYZFoy7mkU-q8RPDd9oQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2012-03-02  6:03       ` Kent Overstreet
       [not found]         ` <CAC7rs0vpQAaF9uNhhy2ziLa+3EB6udJVRjGwf=RVoSk0TxuDcw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 16+ messages in thread
From: Kent Overstreet @ 2012-03-02  6:03 UTC (permalink / raw)
  To: Joseph Glanville; +Cc: linux-bcache-u79uwXL29TY76Z2rM5mHXA

Weird.

Did the /dev/bcache0 device get create created by udev?

It's possible my code isn't poking the right thing. *mutters about the
block layer...*

On Thu, Mar 1, 2012 at 9:49 PM, Joseph Glanville
<joseph.glanville-2MxvZkOi9dvvnOemgxGiVw@public.gmane.org> wrote:
> Hi,
>
> I can't use bcache devices as members of lvm volume groups because
> dmsetup can't find the devices.
> It provides the ever useful feedback of:
> # pvcreate /dev/bcache0
>   Device /dev/bcache0 not found (or ignored by filtering).
>
> My LVM.conf is only filtering out nbd devices:
> filter = [ "r|/dev/nbd.*|", "a/.*/" ]
>
> Any insight would be greatly appreciated. :)
>
> I also noted that bcache devices don't appear in iostat..
>
> Joseph.
>
> --
> Founder | Director | VP Research
> Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
> 99 52 | Mobile: 0428 754 846
>
>
> --
> Founder | Director | VP Research
> Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
> 99 52 | Mobile: 0428 754 846
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: bcache and dm targets (specifically lvm)
       [not found]         ` <CAC7rs0vpQAaF9uNhhy2ziLa+3EB6udJVRjGwf=RVoSk0TxuDcw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2012-03-02  6:44           ` Kent Overstreet
       [not found]             ` <CAC7rs0us5Xqag_AWq=wsFYqn3Fub3qt59a9=vDeS5cLh2oOg0Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 16+ messages in thread
From: Kent Overstreet @ 2012-03-02  6:44 UTC (permalink / raw)
  To: Joseph Glanville; +Cc: linux-bcache-u79uwXL29TY76Z2rM5mHXA

Oh - try stracing the pvcreate and see what happens.

On Thu, Mar 1, 2012 at 10:03 PM, Kent Overstreet
<kent.overstreet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Weird.
>
> Did the /dev/bcache0 device get create created by udev?
>
> It's possible my code isn't poking the right thing. *mutters about the
> block layer...*
>
> On Thu, Mar 1, 2012 at 9:49 PM, Joseph Glanville
> <joseph.glanville-2MxvZkOi9dvvnOemgxGiVw@public.gmane.org> wrote:
>> Hi,
>>
>> I can't use bcache devices as members of lvm volume groups because
>> dmsetup can't find the devices.
>> It provides the ever useful feedback of:
>> # pvcreate /dev/bcache0
>>   Device /dev/bcache0 not found (or ignored by filtering).
>>
>> My LVM.conf is only filtering out nbd devices:
>> filter = [ "r|/dev/nbd.*|", "a/.*/" ]
>>
>> Any insight would be greatly appreciated. :)
>>
>> I also noted that bcache devices don't appear in iostat..
>>
>> Joseph.
>>
>> --
>> Founder | Director | VP Research
>> Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
>> 99 52 | Mobile: 0428 754 846
>>
>>
>> --
>> Founder | Director | VP Research
>> Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
>> 99 52 | Mobile: 0428 754 846
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: bcache and dm targets (specifically lvm)
       [not found]             ` <CAC7rs0us5Xqag_AWq=wsFYqn3Fub3qt59a9=vDeS5cLh2oOg0Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2012-03-02 22:37               ` Joseph Glanville
       [not found]                 ` <CAOzFzEifqyFz2G=0OEPA9BN8-kU3MabUhGmU7-jSQCxwPcHrpw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 16+ messages in thread
From: Joseph Glanville @ 2012-03-02 22:37 UTC (permalink / raw)
  To: Kent Overstreet; +Cc: linux-bcache-u79uwXL29TY76Z2rM5mHXA

Hi Kent,

The block device did indeed get created in /dev and the correct
pointer exists in /sys/block/bcache0/dev
I straced pvcreate and attached the outout, I couldn't see anything
that far out of the ordinary though - bar the return that the device
had been filtered.
I am using commit f4c09286dd3f761310b24bc03e5ce95793a9a30c of
bcache-tools.git and commit 7c3e597ca0f5c87767548d1e9aced024aa558b2a
of linux-bcache.git

The other thing I noticed was that the /dev/disk-by/uuid symlink
wasn't created. I went ahead and created this myself but I will
investigate why the udev rule didn't do this for me.

Below is relevant lines from pvscan and pvcreate:

dev05 ~ # cat pvscan.log | grep bcache
execve("/sbin/pvscan", ["pvscan", "/dev/bcache0"], [/* 23 vars */]) = 0
read(3, "strace\0pvscan\0/dev/bcache0\0", 31) = 27
readlink("/sys/class/block/bcache0",
"../../devices/virtual/block/bcache0"..., 1024) = 35
stat("/sys/devices/virtual/block/bcache0/uevent",
{st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
readlink("/sys/devices/virtual/block/bcache0", 0x7fff9e17aea0, 1024) =
-1 EINVAL (Invalid argument)
stat("/sys/devices/virtual/block/bcache0/uevent",
{st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
open("/sys/devices/virtual/block/bcache0/uevent", O_RDONLY|O_CLOEXEC) = 4
read(4, "MAJOR=252\nMINOR=0\nDEVNAME=bcache"..., 4096) = 47
readlink("/sys/devices/virtual/block/bcache0/subsystem",
"../../../../class/block"..., 1024) = 23
read(4, "N:bcache0\nW:40\nI:580433490\n", 4096) = 27
stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
stat("/sys/class/block/bcache0/dev", {st_mode=S_IFREG|0444,
st_size=4096, ...}) = 0
open("/sys/class/block/bcache0/dev", O_RDONLY) = 6

dev05 ~ # cat pvcreate-strace.log | grep bcache
execve("/sbin/pvcreate", ["pvcreate", "/dev/bcache0"], [/* 23 vars */]) = 0
read(3, "strace\0pvcreate\0/dev/bcache0\0", 31) = 29
stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
readlink("/sys/dev/block/252:0",
"../../devices/virtual/block/bcache0", 1024) = 35
stat("/sys/devices/virtual/block/bcache0/uevent",
{st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
stat("/sys/class/block/bcache0/dev", {st_mode=S_IFREG|0444,
st_size=4096, ...}) = 0
open("/sys/class/block/bcache0/dev", O_RDONLY) = 6
stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
stat("/sys/class/block/bcache0/dev", {st_mode=S_IFREG|0444,
st_size=4096, ...}) = 0
open("/sys/class/block/bcache0/dev", O_RDONLY) = 6
write(2, "Device /dev/bcache0 not found (o"..., 56Device /dev/bcache0
not found (or ignored by filtering).) = 56

Kind regards,
Joseph.


On 2 March 2012 17:44, Kent Overstreet <kent.overstreet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Oh - try stracing the pvcreate and see what happens.
>
> On Thu, Mar 1, 2012 at 10:03 PM, Kent Overstreet
> <kent.overstreet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Weird.
>>
>> Did the /dev/bcache0 device get create created by udev?
>>
>> It's possible my code isn't poking the right thing. *mutters about the
>> block layer...*
>>
>> On Thu, Mar 1, 2012 at 9:49 PM, Joseph Glanville
>> <joseph.glanville-2MxvZkOi9dvvnOemgxGiVw@public.gmane.org> wrote:
>>> Hi,
>>>
>>> I can't use bcache devices as members of lvm volume groups because
>>> dmsetup can't find the devices.
>>> It provides the ever useful feedback of:
>>> # pvcreate /dev/bcache0
>>>   Device /dev/bcache0 not found (or ignored by filtering).
>>>
>>> My LVM.conf is only filtering out nbd devices:
>>> filter = [ "r|/dev/nbd.*|", "a/.*/" ]
>>>
>>> Any insight would be greatly appreciated. :)
>>>
>>> I also noted that bcache devices don't appear in iostat..
>>>
>>> Joseph.
>>>
>>> --
>>> Founder | Director | VP Research
>>> Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
>>> 99 52 | Mobile: 0428 754 846
>>>
>>>
>>> --
>>> Founder | Director | VP Research
>>> Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
>>> 99 52 | Mobile: 0428 754 846
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Founder | Director | VP Research
Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
99 52 | Mobile: 0428 754 846

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: bcache and dm targets (specifically lvm)
       [not found]                 ` <CAOzFzEifqyFz2G=0OEPA9BN8-kU3MabUhGmU7-jSQCxwPcHrpw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2012-03-03  0:01                   ` Kent Overstreet
       [not found]                     ` <CAH+dOx+eWJKvKz=HEGHaPu8tqqz2CqVjUC1+0GJqta0GE4aYNw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 16+ messages in thread
From: Kent Overstreet @ 2012-03-03  0:01 UTC (permalink / raw)
  To: Joseph Glanville; +Cc: Kent Overstreet, linux-bcache-u79uwXL29TY76Z2rM5mHXA

Strange, I don't see anything obvious in that log. Well, shouldn't be
too hard to track down, I'll see if I can reproduce it.

On Fri, Mar 2, 2012 at 2:37 PM, Joseph Glanville
<joseph.glanville-2MxvZkOi9dvvnOemgxGiVw@public.gmane.org> wrote:
> Hi Kent,
>
> The block device did indeed get created in /dev and the correct
> pointer exists in /sys/block/bcache0/dev
> I straced pvcreate and attached the outout, I couldn't see anything
> that far out of the ordinary though - bar the return that the device
> had been filtered.
> I am using commit f4c09286dd3f761310b24bc03e5ce95793a9a30c of
> bcache-tools.git and commit 7c3e597ca0f5c87767548d1e9aced024aa558b2a
> of linux-bcache.git
>
> The other thing I noticed was that the /dev/disk-by/uuid symlink
> wasn't created. I went ahead and created this myself but I will
> investigate why the udev rule didn't do this for me.
>
> Below is relevant lines from pvscan and pvcreate:
>
> dev05 ~ # cat pvscan.log | grep bcache
> execve("/sbin/pvscan", ["pvscan", "/dev/bcache0"], [/* 23 vars */]) = 0
> read(3, "strace\0pvscan\0/dev/bcache0\0", 31) = 27
> readlink("/sys/class/block/bcache0",
> "../../devices/virtual/block/bcache0"..., 1024) = 35
> stat("/sys/devices/virtual/block/bcache0/uevent",
> {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
> readlink("/sys/devices/virtual/block/bcache0", 0x7fff9e17aea0, 1024) =
> -1 EINVAL (Invalid argument)
> stat("/sys/devices/virtual/block/bcache0/uevent",
> {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
> open("/sys/devices/virtual/block/bcache0/uevent", O_RDONLY|O_CLOEXEC) = 4
> read(4, "MAJOR=252\nMINOR=0\nDEVNAME=bcache"..., 4096) = 47
> readlink("/sys/devices/virtual/block/bcache0/subsystem",
> "../../../../class/block"..., 1024) = 23
> read(4, "N:bcache0\nW:40\nI:580433490\n", 4096) = 27
> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
> stat("/sys/class/block/bcache0/dev", {st_mode=S_IFREG|0444,
> st_size=4096, ...}) = 0
> open("/sys/class/block/bcache0/dev", O_RDONLY) = 6
>
> dev05 ~ # cat pvcreate-strace.log | grep bcache
> execve("/sbin/pvcreate", ["pvcreate", "/dev/bcache0"], [/* 23 vars */]) = 0
> read(3, "strace\0pvcreate\0/dev/bcache0\0", 31) = 29
> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
> readlink("/sys/dev/block/252:0",
> "../../devices/virtual/block/bcache0", 1024) = 35
> stat("/sys/devices/virtual/block/bcache0/uevent",
> {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
> stat("/sys/class/block/bcache0/dev", {st_mode=S_IFREG|0444,
> st_size=4096, ...}) = 0
> open("/sys/class/block/bcache0/dev", O_RDONLY) = 6
> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
> stat("/sys/class/block/bcache0/dev", {st_mode=S_IFREG|0444,
> st_size=4096, ...}) = 0
> open("/sys/class/block/bcache0/dev", O_RDONLY) = 6
> write(2, "Device /dev/bcache0 not found (o"..., 56Device /dev/bcache0
> not found (or ignored by filtering).) = 56
>
> Kind regards,
> Joseph.
>
>
> On 2 March 2012 17:44, Kent Overstreet <kent.overstreet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Oh - try stracing the pvcreate and see what happens.
>>
>> On Thu, Mar 1, 2012 at 10:03 PM, Kent Overstreet
>> <kent.overstreet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> Weird.
>>>
>>> Did the /dev/bcache0 device get create created by udev?
>>>
>>> It's possible my code isn't poking the right thing. *mutters about the
>>> block layer...*
>>>
>>> On Thu, Mar 1, 2012 at 9:49 PM, Joseph Glanville
>>> <joseph.glanville-2MxvZkOi9dvvnOemgxGiVw@public.gmane.org> wrote:
>>>> Hi,
>>>>
>>>> I can't use bcache devices as members of lvm volume groups because
>>>> dmsetup can't find the devices.
>>>> It provides the ever useful feedback of:
>>>> # pvcreate /dev/bcache0
>>>>   Device /dev/bcache0 not found (or ignored by filtering).
>>>>
>>>> My LVM.conf is only filtering out nbd devices:
>>>> filter = [ "r|/dev/nbd.*|", "a/.*/" ]
>>>>
>>>> Any insight would be greatly appreciated. :)
>>>>
>>>> I also noted that bcache devices don't appear in iostat..
>>>>
>>>> Joseph.
>>>>
>>>> --
>>>> Founder | Director | VP Research
>>>> Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
>>>> 99 52 | Mobile: 0428 754 846
>>>>
>>>>
>>>> --
>>>> Founder | Director | VP Research
>>>> Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
>>>> 99 52 | Mobile: 0428 754 846
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>>>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Founder | Director | VP Research
> Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
> 99 52 | Mobile: 0428 754 846
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: bcache and dm targets (specifically lvm)
       [not found]                     ` <CAH+dOx+eWJKvKz=HEGHaPu8tqqz2CqVjUC1+0GJqta0GE4aYNw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2012-03-03  0:48                       ` Joseph Glanville
       [not found]                         ` <CAOzFzEj=gBXL9UaVytrebU3gr2p1rJaMVPkz1X0oZOALQKbcNA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 16+ messages in thread
From: Joseph Glanville @ 2012-03-03  0:48 UTC (permalink / raw)
  To: Kent Overstreet; +Cc: Kent Overstreet, linux-bcache-u79uwXL29TY76Z2rM5mHXA

Cheers, I will try with a full disk device sometime later today.

Thanks for you help,
Joseph.

On 3 March 2012 11:01, Kent Overstreet <koverstreet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
> Strange, I don't see anything obvious in that log. Well, shouldn't be
> too hard to track down, I'll see if I can reproduce it.
>
> On Fri, Mar 2, 2012 at 2:37 PM, Joseph Glanville
> <joseph.glanville-2MxvZkOi9dvvnOemgxGiVw@public.gmane.org> wrote:
>> Hi Kent,
>>
>> The block device did indeed get created in /dev and the correct
>> pointer exists in /sys/block/bcache0/dev
>> I straced pvcreate and attached the outout, I couldn't see anything
>> that far out of the ordinary though - bar the return that the device
>> had been filtered.
>> I am using commit f4c09286dd3f761310b24bc03e5ce95793a9a30c of
>> bcache-tools.git and commit 7c3e597ca0f5c87767548d1e9aced024aa558b2a
>> of linux-bcache.git
>>
>> The other thing I noticed was that the /dev/disk-by/uuid symlink
>> wasn't created. I went ahead and created this myself but I will
>> investigate why the udev rule didn't do this for me.
>>
>> Below is relevant lines from pvscan and pvcreate:
>>
>> dev05 ~ # cat pvscan.log | grep bcache
>> execve("/sbin/pvscan", ["pvscan", "/dev/bcache0"], [/* 23 vars */]) = 0
>> read(3, "strace\0pvscan\0/dev/bcache0\0", 31) = 27
>> readlink("/sys/class/block/bcache0",
>> "../../devices/virtual/block/bcache0"..., 1024) = 35
>> stat("/sys/devices/virtual/block/bcache0/uevent",
>> {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
>> readlink("/sys/devices/virtual/block/bcache0", 0x7fff9e17aea0, 1024) =
>> -1 EINVAL (Invalid argument)
>> stat("/sys/devices/virtual/block/bcache0/uevent",
>> {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
>> open("/sys/devices/virtual/block/bcache0/uevent", O_RDONLY|O_CLOEXEC) = 4
>> read(4, "MAJOR=252\nMINOR=0\nDEVNAME=bcache"..., 4096) = 47
>> readlink("/sys/devices/virtual/block/bcache0/subsystem",
>> "../../../../class/block"..., 1024) = 23
>> read(4, "N:bcache0\nW:40\nI:580433490\n", 4096) = 27
>> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
>> stat("/sys/class/block/bcache0/dev", {st_mode=S_IFREG|0444,
>> st_size=4096, ...}) = 0
>> open("/sys/class/block/bcache0/dev", O_RDONLY) = 6
>>
>> dev05 ~ # cat pvcreate-strace.log | grep bcache
>> execve("/sbin/pvcreate", ["pvcreate", "/dev/bcache0"], [/* 23 vars */]) = 0
>> read(3, "strace\0pvcreate\0/dev/bcache0\0", 31) = 29
>> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
>> readlink("/sys/dev/block/252:0",
>> "../../devices/virtual/block/bcache0", 1024) = 35
>> stat("/sys/devices/virtual/block/bcache0/uevent",
>> {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
>> stat("/sys/class/block/bcache0/dev", {st_mode=S_IFREG|0444,
>> st_size=4096, ...}) = 0
>> open("/sys/class/block/bcache0/dev", O_RDONLY) = 6
>> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
>> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
>> stat("/sys/class/block/bcache0/dev", {st_mode=S_IFREG|0444,
>> st_size=4096, ...}) = 0
>> open("/sys/class/block/bcache0/dev", O_RDONLY) = 6
>> write(2, "Device /dev/bcache0 not found (o"..., 56Device /dev/bcache0
>> not found (or ignored by filtering).) = 56
>>
>> Kind regards,
>> Joseph.
>>
>>
>> On 2 March 2012 17:44, Kent Overstreet <kent.overstreet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> Oh - try stracing the pvcreate and see what happens.
>>>
>>> On Thu, Mar 1, 2012 at 10:03 PM, Kent Overstreet
>>> <kent.overstreet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>> Weird.
>>>>
>>>> Did the /dev/bcache0 device get create created by udev?
>>>>
>>>> It's possible my code isn't poking the right thing. *mutters about the
>>>> block layer...*
>>>>
>>>> On Thu, Mar 1, 2012 at 9:49 PM, Joseph Glanville
>>>> <joseph.glanville-2MxvZkOi9dvvnOemgxGiVw@public.gmane.org> wrote:
>>>>> Hi,
>>>>>
>>>>> I can't use bcache devices as members of lvm volume groups because
>>>>> dmsetup can't find the devices.
>>>>> It provides the ever useful feedback of:
>>>>> # pvcreate /dev/bcache0
>>>>>   Device /dev/bcache0 not found (or ignored by filtering).
>>>>>
>>>>> My LVM.conf is only filtering out nbd devices:
>>>>> filter = [ "r|/dev/nbd.*|", "a/.*/" ]
>>>>>
>>>>> Any insight would be greatly appreciated. :)
>>>>>
>>>>> I also noted that bcache devices don't appear in iostat..
>>>>>
>>>>> Joseph.
>>>>>
>>>>> --
>>>>> Founder | Director | VP Research
>>>>> Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
>>>>> 99 52 | Mobile: 0428 754 846
>>>>>
>>>>>
>>>>> --
>>>>> Founder | Director | VP Research
>>>>> Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
>>>>> 99 52 | Mobile: 0428 754 846
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>>>>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>> --
>> Founder | Director | VP Research
>> Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
>> 99 52 | Mobile: 0428 754 846
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Founder | Director | VP Research
Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
99 52 | Mobile: 0428 754 846

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: bcache and dm targets (specifically lvm)
  2012-03-03  0:48                       ` Joseph Glanville
@ 2012-03-03  2:17                             ` Kent Overstreet
  0 siblings, 0 replies; 16+ messages in thread
From: Kent Overstreet @ 2012-03-03  2:17 UTC (permalink / raw)
  To: Joseph Glanville
  Cc: Kent Overstreet, linux-bcache-u79uwXL29TY76Z2rM5mHXA,
	linux-lvm-H+wXaHxf7aLQT0dZR+AlfA

I found the bug. Ugh...

pvcreate refuses to use a device it doesn't recognize - look at the
lvm2 source, lib/filters/filter.c

I don't know why and I don't think I want to know. I imagine it'd work
if you commented out the offending check (line 143 in my version).

Maybe one of them can explain what's going on.

On Fri, Mar 2, 2012 at 4:48 PM, Joseph Glanville
<joseph.glanville-2MxvZkOi9dvvnOemgxGiVw@public.gmane.org> wrote:
> Cheers, I will try with a full disk device sometime later today.
>
> Thanks for you help,
> Joseph.
>
> On 3 March 2012 11:01, Kent Overstreet <koverstreet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
>> Strange, I don't see anything obvious in that log. Well, shouldn't be
>> too hard to track down, I'll see if I can reproduce it.
>>
>> On Fri, Mar 2, 2012 at 2:37 PM, Joseph Glanville
>> <joseph.glanville-2MxvZkOi9dvvnOemgxGiVw@public.gmane.org> wrote:
>>> Hi Kent,
>>>
>>> The block device did indeed get created in /dev and the correct
>>> pointer exists in /sys/block/bcache0/dev
>>> I straced pvcreate and attached the outout, I couldn't see anything
>>> that far out of the ordinary though - bar the return that the device
>>> had been filtered.
>>> I am using commit f4c09286dd3f761310b24bc03e5ce95793a9a30c of
>>> bcache-tools.git and commit 7c3e597ca0f5c87767548d1e9aced024aa558b2a
>>> of linux-bcache.git
>>>
>>> The other thing I noticed was that the /dev/disk-by/uuid symlink
>>> wasn't created. I went ahead and created this myself but I will
>>> investigate why the udev rule didn't do this for me.
>>>
>>> Below is relevant lines from pvscan and pvcreate:
>>>
>>> dev05 ~ # cat pvscan.log | grep bcache
>>> execve("/sbin/pvscan", ["pvscan", "/dev/bcache0"], [/* 23 vars */]) = 0
>>> read(3, "strace\0pvscan\0/dev/bcache0\0", 31) = 27
>>> readlink("/sys/class/block/bcache0",
>>> "../../devices/virtual/block/bcache0"..., 1024) = 35
>>> stat("/sys/devices/virtual/block/bcache0/uevent",
>>> {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
>>> readlink("/sys/devices/virtual/block/bcache0", 0x7fff9e17aea0, 1024) =
>>> -1 EINVAL (Invalid argument)
>>> stat("/sys/devices/virtual/block/bcache0/uevent",
>>> {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
>>> open("/sys/devices/virtual/block/bcache0/uevent", O_RDONLY|O_CLOEXEC) = 4
>>> read(4, "MAJOR=252\nMINOR=0\nDEVNAME=bcache"..., 4096) = 47
>>> readlink("/sys/devices/virtual/block/bcache0/subsystem",
>>> "../../../../class/block"..., 1024) = 23
>>> read(4, "N:bcache0\nW:40\nI:580433490\n", 4096) = 27
>>> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
>>> stat("/sys/class/block/bcache0/dev", {st_mode=S_IFREG|0444,
>>> st_size=4096, ...}) = 0
>>> open("/sys/class/block/bcache0/dev", O_RDONLY) = 6
>>>
>>> dev05 ~ # cat pvcreate-strace.log | grep bcache
>>> execve("/sbin/pvcreate", ["pvcreate", "/dev/bcache0"], [/* 23 vars */]) = 0
>>> read(3, "strace\0pvcreate\0/dev/bcache0\0", 31) = 29
>>> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
>>> readlink("/sys/dev/block/252:0",
>>> "../../devices/virtual/block/bcache0", 1024) = 35
>>> stat("/sys/devices/virtual/block/bcache0/uevent",
>>> {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
>>> stat("/sys/class/block/bcache0/dev", {st_mode=S_IFREG|0444,
>>> st_size=4096, ...}) = 0
>>> open("/sys/class/block/bcache0/dev", O_RDONLY) = 6
>>> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
>>> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
>>> stat("/sys/class/block/bcache0/dev", {st_mode=S_IFREG|0444,
>>> st_size=4096, ...}) = 0
>>> open("/sys/class/block/bcache0/dev", O_RDONLY) = 6
>>> write(2, "Device /dev/bcache0 not found (o"..., 56Device /dev/bcache0
>>> not found (or ignored by filtering).) = 56
>>>
>>> Kind regards,
>>> Joseph.
>>>
>>>
>>> On 2 March 2012 17:44, Kent Overstreet <kent.overstreet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>> Oh - try stracing the pvcreate and see what happens.
>>>>
>>>> On Thu, Mar 1, 2012 at 10:03 PM, Kent Overstreet
>>>> <kent.overstreet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>> Weird.
>>>>>
>>>>> Did the /dev/bcache0 device get create created by udev?
>>>>>
>>>>> It's possible my code isn't poking the right thing. *mutters about the
>>>>> block layer...*
>>>>>
>>>>> On Thu, Mar 1, 2012 at 9:49 PM, Joseph Glanville
>>>>> <joseph.glanville-2MxvZkOi9dvvnOemgxGiVw@public.gmane.org> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I can't use bcache devices as members of lvm volume groups because
>>>>>> dmsetup can't find the devices.
>>>>>> It provides the ever useful feedback of:
>>>>>> # pvcreate /dev/bcache0
>>>>>>   Device /dev/bcache0 not found (or ignored by filtering).
>>>>>>
>>>>>> My LVM.conf is only filtering out nbd devices:
>>>>>> filter = [ "r|/dev/nbd.*|", "a/.*/" ]
>>>>>>
>>>>>> Any insight would be greatly appreciated. :)
>>>>>>
>>>>>> I also noted that bcache devices don't appear in iostat..
>>>>>>
>>>>>> Joseph.
>>>>>>
>>>>>> --
>>>>>> Founder | Director | VP Research
>>>>>> Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
>>>>>> 99 52 | Mobile: 0428 754 846
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Founder | Director | VP Research
>>>>>> Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
>>>>>> 99 52 | Mobile: 0428 754 846
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>>>>>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>>
>>> --
>>> Founder | Director | VP Research
>>> Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
>>> 99 52 | Mobile: 0428 754 846
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Founder | Director | VP Research
> Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
> 99 52 | Mobile: 0428 754 846

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [linux-lvm] bcache and dm targets (specifically lvm)
@ 2012-03-03  2:17                             ` Kent Overstreet
  0 siblings, 0 replies; 16+ messages in thread
From: Kent Overstreet @ 2012-03-03  2:17 UTC (permalink / raw)
  To: Joseph Glanville; +Cc: linux-bcache, Kent Overstreet, linux-lvm

I found the bug. Ugh...

pvcreate refuses to use a device it doesn't recognize - look at the
lvm2 source, lib/filters/filter.c

I don't know why and I don't think I want to know. I imagine it'd work
if you commented out the offending check (line 143 in my version).

Maybe one of them can explain what's going on.

On Fri, Mar 2, 2012 at 4:48 PM, Joseph Glanville
<joseph.glanville@orionvm.com.au> wrote:
> Cheers, I will try with a full disk device sometime later today.
>
> Thanks for you help,
> Joseph.
>
> On 3 March 2012 11:01, Kent Overstreet <koverstreet@google.com> wrote:
>> Strange, I don't see anything obvious in that log. Well, shouldn't be
>> too hard to track down, I'll see if I can reproduce it.
>>
>> On Fri, Mar 2, 2012 at 2:37 PM, Joseph Glanville
>> <joseph.glanville@orionvm.com.au> wrote:
>>> Hi Kent,
>>>
>>> The block device did indeed get created in /dev and the correct
>>> pointer exists in /sys/block/bcache0/dev
>>> I straced pvcreate and attached the outout, I couldn't see anything
>>> that far out of the ordinary though - bar the return that the device
>>> had been filtered.
>>> I am using commit f4c09286dd3f761310b24bc03e5ce95793a9a30c of
>>> bcache-tools.git and commit 7c3e597ca0f5c87767548d1e9aced024aa558b2a
>>> of linux-bcache.git
>>>
>>> The other thing I noticed was that the /dev/disk-by/uuid symlink
>>> wasn't created. I went ahead and created this myself but I will
>>> investigate why the udev rule didn't do this for me.
>>>
>>> Below is relevant lines from pvscan and pvcreate:
>>>
>>> dev05 ~ # cat pvscan.log | grep bcache
>>> execve("/sbin/pvscan", ["pvscan", "/dev/bcache0"], [/* 23 vars */]) = 0
>>> read(3, "strace\0pvscan\0/dev/bcache0\0", 31) = 27
>>> readlink("/sys/class/block/bcache0",
>>> "../../devices/virtual/block/bcache0"..., 1024) = 35
>>> stat("/sys/devices/virtual/block/bcache0/uevent",
>>> {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
>>> readlink("/sys/devices/virtual/block/bcache0", 0x7fff9e17aea0, 1024) =
>>> -1 EINVAL (Invalid argument)
>>> stat("/sys/devices/virtual/block/bcache0/uevent",
>>> {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
>>> open("/sys/devices/virtual/block/bcache0/uevent", O_RDONLY|O_CLOEXEC) = 4
>>> read(4, "MAJOR=252\nMINOR=0\nDEVNAME=bcache"..., 4096) = 47
>>> readlink("/sys/devices/virtual/block/bcache0/subsystem",
>>> "../../../../class/block"..., 1024) = 23
>>> read(4, "N:bcache0\nW:40\nI:580433490\n", 4096) = 27
>>> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
>>> stat("/sys/class/block/bcache0/dev", {st_mode=S_IFREG|0444,
>>> st_size=4096, ...}) = 0
>>> open("/sys/class/block/bcache0/dev", O_RDONLY) = 6
>>>
>>> dev05 ~ # cat pvcreate-strace.log | grep bcache
>>> execve("/sbin/pvcreate", ["pvcreate", "/dev/bcache0"], [/* 23 vars */]) = 0
>>> read(3, "strace\0pvcreate\0/dev/bcache0\0", 31) = 29
>>> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
>>> readlink("/sys/dev/block/252:0",
>>> "../../devices/virtual/block/bcache0", 1024) = 35
>>> stat("/sys/devices/virtual/block/bcache0/uevent",
>>> {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
>>> stat("/sys/class/block/bcache0/dev", {st_mode=S_IFREG|0444,
>>> st_size=4096, ...}) = 0
>>> open("/sys/class/block/bcache0/dev", O_RDONLY) = 6
>>> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
>>> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
>>> stat("/sys/class/block/bcache0/dev", {st_mode=S_IFREG|0444,
>>> st_size=4096, ...}) = 0
>>> open("/sys/class/block/bcache0/dev", O_RDONLY) = 6
>>> write(2, "Device /dev/bcache0 not found (o"..., 56Device /dev/bcache0
>>> not found (or ignored by filtering).) = 56
>>>
>>> Kind regards,
>>> Joseph.
>>>
>>>
>>> On 2 March 2012 17:44, Kent Overstreet <kent.overstreet@gmail.com> wrote:
>>>> Oh - try stracing the pvcreate and see what happens.
>>>>
>>>> On Thu, Mar 1, 2012 at 10:03 PM, Kent Overstreet
>>>> <kent.overstreet@gmail.com> wrote:
>>>>> Weird.
>>>>>
>>>>> Did the /dev/bcache0 device get create created by udev?
>>>>>
>>>>> It's possible my code isn't poking the right thing. *mutters about the
>>>>> block layer...*
>>>>>
>>>>> On Thu, Mar 1, 2012 at 9:49 PM, Joseph Glanville
>>>>> <joseph.glanville@orionvm.com.au> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I can't use bcache devices as members of lvm volume groups because
>>>>>> dmsetup can't find the devices.
>>>>>> It provides the ever useful feedback of:
>>>>>> # pvcreate /dev/bcache0
>>>>>> � Device /dev/bcache0 not found (or ignored by filtering).
>>>>>>
>>>>>> My LVM.conf is only filtering out nbd devices:
>>>>>> filter = [ "r|/dev/nbd.*|", "a/.*/" ]
>>>>>>
>>>>>> Any insight would be greatly appreciated. :)
>>>>>>
>>>>>> I also noted that bcache devices don't appear in iostat..
>>>>>>
>>>>>> Joseph.
>>>>>>
>>>>>> --
>>>>>> Founder | Director | VP Research
>>>>>> Orion Virtualisation Solutions�|�www.orionvm.com.au�| Phone: 1300 56
>>>>>> 99 52 | Mobile: 0428 754 846
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Founder | Director | VP Research
>>>>>> Orion Virtualisation Solutions�|�www.orionvm.com.au�| Phone: 1300 56
>>>>>> 99 52 | Mobile: 0428 754 846
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at �http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>>
>>> --
>>> Founder | Director | VP Research
>>> Orion Virtualisation Solutions�|�www.orionvm.com.au�| Phone: 1300 56
>>> 99 52 | Mobile: 0428 754 846
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at �http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Founder | Director | VP Research
> Orion Virtualisation Solutions�|�www.orionvm.com.au�| Phone: 1300 56
> 99 52 | Mobile: 0428 754 846

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: bcache and dm targets (specifically lvm)
  2012-03-03  2:17                             ` [linux-lvm] " Kent Overstreet
@ 2012-03-03  2:28                                 ` Joseph Glanville
  -1 siblings, 0 replies; 16+ messages in thread
From: Joseph Glanville @ 2012-03-03  2:28 UTC (permalink / raw)
  To: Kent Overstreet
  Cc: Kent Overstreet, linux-bcache-u79uwXL29TY76Z2rM5mHXA,
	linux-lvm-H+wXaHxf7aLQT0dZR+AlfA

Ahh!

I didn't know LVM had a device type lookup table. You can see if you
look further that it also reads new types from the lvm.conf file.
Adding this line to lvm.conf fixes the problem:

types = [ "bcache", 16 ]

I would imagine if merged it would be added to the internal compiled in table.

Thanks for the pointer.
Joseph.

On 3 March 2012 13:17, Kent Overstreet <koverstreet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
> I found the bug. Ugh...
>
> pvcreate refuses to use a device it doesn't recognize - look at the
> lvm2 source, lib/filters/filter.c
>
> I don't know why and I don't think I want to know. I imagine it'd work
> if you commented out the offending check (line 143 in my version).
>
> Maybe one of them can explain what's going on.
>
> On Fri, Mar 2, 2012 at 4:48 PM, Joseph Glanville
> <joseph.glanville-2MxvZkOi9dvvnOemgxGiVw@public.gmane.org> wrote:
>> Cheers, I will try with a full disk device sometime later today.
>>
>> Thanks for you help,
>> Joseph.
>>
>> On 3 March 2012 11:01, Kent Overstreet <koverstreet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
>>> Strange, I don't see anything obvious in that log. Well, shouldn't be
>>> too hard to track down, I'll see if I can reproduce it.
>>>
>>> On Fri, Mar 2, 2012 at 2:37 PM, Joseph Glanville
>>> <joseph.glanville-2MxvZkOi9dvvnOemgxGiVw@public.gmane.org> wrote:
>>>> Hi Kent,
>>>>
>>>> The block device did indeed get created in /dev and the correct
>>>> pointer exists in /sys/block/bcache0/dev
>>>> I straced pvcreate and attached the outout, I couldn't see anything
>>>> that far out of the ordinary though - bar the return that the device
>>>> had been filtered.
>>>> I am using commit f4c09286dd3f761310b24bc03e5ce95793a9a30c of
>>>> bcache-tools.git and commit 7c3e597ca0f5c87767548d1e9aced024aa558b2a
>>>> of linux-bcache.git
>>>>
>>>> The other thing I noticed was that the /dev/disk-by/uuid symlink
>>>> wasn't created. I went ahead and created this myself but I will
>>>> investigate why the udev rule didn't do this for me.
>>>>
>>>> Below is relevant lines from pvscan and pvcreate:
>>>>
>>>> dev05 ~ # cat pvscan.log | grep bcache
>>>> execve("/sbin/pvscan", ["pvscan", "/dev/bcache0"], [/* 23 vars */]) = 0
>>>> read(3, "strace\0pvscan\0/dev/bcache0\0", 31) = 27
>>>> readlink("/sys/class/block/bcache0",
>>>> "../../devices/virtual/block/bcache0"..., 1024) = 35
>>>> stat("/sys/devices/virtual/block/bcache0/uevent",
>>>> {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
>>>> readlink("/sys/devices/virtual/block/bcache0", 0x7fff9e17aea0, 1024) =
>>>> -1 EINVAL (Invalid argument)
>>>> stat("/sys/devices/virtual/block/bcache0/uevent",
>>>> {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
>>>> open("/sys/devices/virtual/block/bcache0/uevent", O_RDONLY|O_CLOEXEC) = 4
>>>> read(4, "MAJOR=252\nMINOR=0\nDEVNAME=bcache"..., 4096) = 47
>>>> readlink("/sys/devices/virtual/block/bcache0/subsystem",
>>>> "../../../../class/block"..., 1024) = 23
>>>> read(4, "N:bcache0\nW:40\nI:580433490\n", 4096) = 27
>>>> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
>>>> stat("/sys/class/block/bcache0/dev", {st_mode=S_IFREG|0444,
>>>> st_size=4096, ...}) = 0
>>>> open("/sys/class/block/bcache0/dev", O_RDONLY) = 6
>>>>
>>>> dev05 ~ # cat pvcreate-strace.log | grep bcache
>>>> execve("/sbin/pvcreate", ["pvcreate", "/dev/bcache0"], [/* 23 vars */]) = 0
>>>> read(3, "strace\0pvcreate\0/dev/bcache0\0", 31) = 29
>>>> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
>>>> readlink("/sys/dev/block/252:0",
>>>> "../../devices/virtual/block/bcache0", 1024) = 35
>>>> stat("/sys/devices/virtual/block/bcache0/uevent",
>>>> {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
>>>> stat("/sys/class/block/bcache0/dev", {st_mode=S_IFREG|0444,
>>>> st_size=4096, ...}) = 0
>>>> open("/sys/class/block/bcache0/dev", O_RDONLY) = 6
>>>> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
>>>> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
>>>> stat("/sys/class/block/bcache0/dev", {st_mode=S_IFREG|0444,
>>>> st_size=4096, ...}) = 0
>>>> open("/sys/class/block/bcache0/dev", O_RDONLY) = 6
>>>> write(2, "Device /dev/bcache0 not found (o"..., 56Device /dev/bcache0
>>>> not found (or ignored by filtering).) = 56
>>>>
>>>> Kind regards,
>>>> Joseph.
>>>>
>>>>
>>>> On 2 March 2012 17:44, Kent Overstreet <kent.overstreet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>> Oh - try stracing the pvcreate and see what happens.
>>>>>
>>>>> On Thu, Mar 1, 2012 at 10:03 PM, Kent Overstreet
>>>>> <kent.overstreet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>>> Weird.
>>>>>>
>>>>>> Did the /dev/bcache0 device get create created by udev?
>>>>>>
>>>>>> It's possible my code isn't poking the right thing. *mutters about the
>>>>>> block layer...*
>>>>>>
>>>>>> On Thu, Mar 1, 2012 at 9:49 PM, Joseph Glanville
>>>>>> <joseph.glanville-2MxvZkOi9dvvnOemgxGiVw@public.gmane.org> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I can't use bcache devices as members of lvm volume groups because
>>>>>>> dmsetup can't find the devices.
>>>>>>> It provides the ever useful feedback of:
>>>>>>> # pvcreate /dev/bcache0
>>>>>>>   Device /dev/bcache0 not found (or ignored by filtering).
>>>>>>>
>>>>>>> My LVM.conf is only filtering out nbd devices:
>>>>>>> filter = [ "r|/dev/nbd.*|", "a/.*/" ]
>>>>>>>
>>>>>>> Any insight would be greatly appreciated. :)
>>>>>>>
>>>>>>> I also noted that bcache devices don't appear in iostat..
>>>>>>>
>>>>>>> Joseph.
>>>>>>>
>>>>>>> --
>>>>>>> Founder | Director | VP Research
>>>>>>> Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
>>>>>>> 99 52 | Mobile: 0428 754 846
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Founder | Director | VP Research
>>>>>>> Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
>>>>>>> 99 52 | Mobile: 0428 754 846
>>>>>>> --
>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>>>>>>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>>>
>>>>
>>>> --
>>>> Founder | Director | VP Research
>>>> Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
>>>> 99 52 | Mobile: 0428 754 846
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>>>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>> --
>> Founder | Director | VP Research
>> Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
>> 99 52 | Mobile: 0428 754 846



-- 
Founder | Director | VP Research
Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
99 52 | Mobile: 0428 754 846

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [linux-lvm] bcache and dm targets (specifically lvm)
@ 2012-03-03  2:28                                 ` Joseph Glanville
  0 siblings, 0 replies; 16+ messages in thread
From: Joseph Glanville @ 2012-03-03  2:28 UTC (permalink / raw)
  To: Kent Overstreet; +Cc: linux-bcache, Kent Overstreet, linux-lvm

Ahh!

I didn't know LVM had a device type lookup table. You can see if you
look further that it also reads new types from the lvm.conf file.
Adding this line to lvm.conf fixes the problem:

types = [ "bcache", 16 ]

I would imagine if merged it would be added to the internal compiled in table.

Thanks for the pointer.
Joseph.

On 3 March 2012 13:17, Kent Overstreet <koverstreet@google.com> wrote:
> I found the bug. Ugh...
>
> pvcreate refuses to use a device it doesn't recognize - look at the
> lvm2 source, lib/filters/filter.c
>
> I don't know why and I don't think I want to know. I imagine it'd work
> if you commented out the offending check (line 143 in my version).
>
> Maybe one of them can explain what's going on.
>
> On Fri, Mar 2, 2012 at 4:48 PM, Joseph Glanville
> <joseph.glanville@orionvm.com.au> wrote:
>> Cheers, I will try with a full disk device sometime later today.
>>
>> Thanks for you help,
>> Joseph.
>>
>> On 3 March 2012 11:01, Kent Overstreet <koverstreet@google.com> wrote:
>>> Strange, I don't see anything obvious in that log. Well, shouldn't be
>>> too hard to track down, I'll see if I can reproduce it.
>>>
>>> On Fri, Mar 2, 2012 at 2:37 PM, Joseph Glanville
>>> <joseph.glanville@orionvm.com.au> wrote:
>>>> Hi Kent,
>>>>
>>>> The block device did indeed get created in /dev and the correct
>>>> pointer exists in /sys/block/bcache0/dev
>>>> I straced pvcreate and attached the outout, I couldn't see anything
>>>> that far out of the ordinary though - bar the return that the device
>>>> had been filtered.
>>>> I am using commit f4c09286dd3f761310b24bc03e5ce95793a9a30c of
>>>> bcache-tools.git and commit 7c3e597ca0f5c87767548d1e9aced024aa558b2a
>>>> of linux-bcache.git
>>>>
>>>> The other thing I noticed was that the /dev/disk-by/uuid symlink
>>>> wasn't created. I went ahead and created this myself but I will
>>>> investigate why the udev rule didn't do this for me.
>>>>
>>>> Below is relevant lines from pvscan and pvcreate:
>>>>
>>>> dev05 ~ # cat pvscan.log | grep bcache
>>>> execve("/sbin/pvscan", ["pvscan", "/dev/bcache0"], [/* 23 vars */]) = 0
>>>> read(3, "strace\0pvscan\0/dev/bcache0\0", 31) = 27
>>>> readlink("/sys/class/block/bcache0",
>>>> "../../devices/virtual/block/bcache0"..., 1024) = 35
>>>> stat("/sys/devices/virtual/block/bcache0/uevent",
>>>> {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
>>>> readlink("/sys/devices/virtual/block/bcache0", 0x7fff9e17aea0, 1024) =
>>>> -1 EINVAL (Invalid argument)
>>>> stat("/sys/devices/virtual/block/bcache0/uevent",
>>>> {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
>>>> open("/sys/devices/virtual/block/bcache0/uevent", O_RDONLY|O_CLOEXEC) = 4
>>>> read(4, "MAJOR=252\nMINOR=0\nDEVNAME=bcache"..., 4096) = 47
>>>> readlink("/sys/devices/virtual/block/bcache0/subsystem",
>>>> "../../../../class/block"..., 1024) = 23
>>>> read(4, "N:bcache0\nW:40\nI:580433490\n", 4096) = 27
>>>> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
>>>> stat("/sys/class/block/bcache0/dev", {st_mode=S_IFREG|0444,
>>>> st_size=4096, ...}) = 0
>>>> open("/sys/class/block/bcache0/dev", O_RDONLY) = 6
>>>>
>>>> dev05 ~ # cat pvcreate-strace.log | grep bcache
>>>> execve("/sbin/pvcreate", ["pvcreate", "/dev/bcache0"], [/* 23 vars */]) = 0
>>>> read(3, "strace\0pvcreate\0/dev/bcache0\0", 31) = 29
>>>> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
>>>> readlink("/sys/dev/block/252:0",
>>>> "../../devices/virtual/block/bcache0", 1024) = 35
>>>> stat("/sys/devices/virtual/block/bcache0/uevent",
>>>> {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
>>>> stat("/sys/class/block/bcache0/dev", {st_mode=S_IFREG|0444,
>>>> st_size=4096, ...}) = 0
>>>> open("/sys/class/block/bcache0/dev", O_RDONLY) = 6
>>>> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
>>>> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
>>>> stat("/sys/class/block/bcache0/dev", {st_mode=S_IFREG|0444,
>>>> st_size=4096, ...}) = 0
>>>> open("/sys/class/block/bcache0/dev", O_RDONLY) = 6
>>>> write(2, "Device /dev/bcache0 not found (o"..., 56Device /dev/bcache0
>>>> not found (or ignored by filtering).) = 56
>>>>
>>>> Kind regards,
>>>> Joseph.
>>>>
>>>>
>>>> On 2 March 2012 17:44, Kent Overstreet <kent.overstreet@gmail.com> wrote:
>>>>> Oh - try stracing the pvcreate and see what happens.
>>>>>
>>>>> On Thu, Mar 1, 2012 at 10:03 PM, Kent Overstreet
>>>>> <kent.overstreet@gmail.com> wrote:
>>>>>> Weird.
>>>>>>
>>>>>> Did the /dev/bcache0 device get create created by udev?
>>>>>>
>>>>>> It's possible my code isn't poking the right thing. *mutters about the
>>>>>> block layer...*
>>>>>>
>>>>>> On Thu, Mar 1, 2012 at 9:49 PM, Joseph Glanville
>>>>>> <joseph.glanville@orionvm.com.au> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I can't use bcache devices as members of lvm volume groups because
>>>>>>> dmsetup can't find the devices.
>>>>>>> It provides the ever useful feedback of:
>>>>>>> # pvcreate /dev/bcache0
>>>>>>> � Device /dev/bcache0 not found (or ignored by filtering).
>>>>>>>
>>>>>>> My LVM.conf is only filtering out nbd devices:
>>>>>>> filter = [ "r|/dev/nbd.*|", "a/.*/" ]
>>>>>>>
>>>>>>> Any insight would be greatly appreciated. :)
>>>>>>>
>>>>>>> I also noted that bcache devices don't appear in iostat..
>>>>>>>
>>>>>>> Joseph.
>>>>>>>
>>>>>>> --
>>>>>>> Founder | Director | VP Research
>>>>>>> Orion Virtualisation Solutions�|�www.orionvm.com.au�| Phone: 1300 56
>>>>>>> 99 52 | Mobile: 0428 754 846
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Founder | Director | VP Research
>>>>>>> Orion Virtualisation Solutions�|�www.orionvm.com.au�| Phone: 1300 56
>>>>>>> 99 52 | Mobile: 0428 754 846
>>>>>>> --
>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>> More majordomo info at �http://vger.kernel.org/majordomo-info.html
>>>>
>>>>
>>>>
>>>> --
>>>> Founder | Director | VP Research
>>>> Orion Virtualisation Solutions�|�www.orionvm.com.au�| Phone: 1300 56
>>>> 99 52 | Mobile: 0428 754 846
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at �http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>> --
>> Founder | Director | VP Research
>> Orion Virtualisation Solutions�|�www.orionvm.com.au�| Phone: 1300 56
>> 99 52 | Mobile: 0428 754 846



-- 
Founder | Director | VP Research
Orion Virtualisation Solutions�|�www.orionvm.com.au�| Phone: 1300 56
99 52 | Mobile: 0428 754 846

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: bcache and dm targets (specifically lvm)
  2012-03-03  2:28                                 ` [linux-lvm] " Joseph Glanville
@ 2012-03-03  2:44                                     ` Kent Overstreet
  -1 siblings, 0 replies; 16+ messages in thread
From: Kent Overstreet @ 2012-03-03  2:44 UTC (permalink / raw)
  To: Joseph Glanville
  Cc: Kent Overstreet, linux-bcache-u79uwXL29TY76Z2rM5mHXA,
	linux-lvm-H+wXaHxf7aLQT0dZR+AlfA

Oh, good! I thought it'd require a patch, that's much better.

On Fri, Mar 2, 2012 at 6:28 PM, Joseph Glanville
<joseph.glanville-2MxvZkOi9dvvnOemgxGiVw@public.gmane.org> wrote:
> Ahh!
>
> I didn't know LVM had a device type lookup table. You can see if you
> look further that it also reads new types from the lvm.conf file.
> Adding this line to lvm.conf fixes the problem:
>
> types = [ "bcache", 16 ]
>
> I would imagine if merged it would be added to the internal compiled in table.
>
> Thanks for the pointer.
> Joseph.
>
> On 3 March 2012 13:17, Kent Overstreet <koverstreet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
>> I found the bug. Ugh...
>>
>> pvcreate refuses to use a device it doesn't recognize - look at the
>> lvm2 source, lib/filters/filter.c
>>
>> I don't know why and I don't think I want to know. I imagine it'd work
>> if you commented out the offending check (line 143 in my version).
>>
>> Maybe one of them can explain what's going on.
>>
>> On Fri, Mar 2, 2012 at 4:48 PM, Joseph Glanville
>> <joseph.glanville-2MxvZkOi9dvvnOemgxGiVw@public.gmane.org> wrote:
>>> Cheers, I will try with a full disk device sometime later today.
>>>
>>> Thanks for you help,
>>> Joseph.
>>>
>>> On 3 March 2012 11:01, Kent Overstreet <koverstreet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
>>>> Strange, I don't see anything obvious in that log. Well, shouldn't be
>>>> too hard to track down, I'll see if I can reproduce it.
>>>>
>>>> On Fri, Mar 2, 2012 at 2:37 PM, Joseph Glanville
>>>> <joseph.glanville-2MxvZkOi9dvvnOemgxGiVw@public.gmane.org> wrote:
>>>>> Hi Kent,
>>>>>
>>>>> The block device did indeed get created in /dev and the correct
>>>>> pointer exists in /sys/block/bcache0/dev
>>>>> I straced pvcreate and attached the outout, I couldn't see anything
>>>>> that far out of the ordinary though - bar the return that the device
>>>>> had been filtered.
>>>>> I am using commit f4c09286dd3f761310b24bc03e5ce95793a9a30c of
>>>>> bcache-tools.git and commit 7c3e597ca0f5c87767548d1e9aced024aa558b2a
>>>>> of linux-bcache.git
>>>>>
>>>>> The other thing I noticed was that the /dev/disk-by/uuid symlink
>>>>> wasn't created. I went ahead and created this myself but I will
>>>>> investigate why the udev rule didn't do this for me.
>>>>>
>>>>> Below is relevant lines from pvscan and pvcreate:
>>>>>
>>>>> dev05 ~ # cat pvscan.log | grep bcache
>>>>> execve("/sbin/pvscan", ["pvscan", "/dev/bcache0"], [/* 23 vars */]) = 0
>>>>> read(3, "strace\0pvscan\0/dev/bcache0\0", 31) = 27
>>>>> readlink("/sys/class/block/bcache0",
>>>>> "../../devices/virtual/block/bcache0"..., 1024) = 35
>>>>> stat("/sys/devices/virtual/block/bcache0/uevent",
>>>>> {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
>>>>> readlink("/sys/devices/virtual/block/bcache0", 0x7fff9e17aea0, 1024) =
>>>>> -1 EINVAL (Invalid argument)
>>>>> stat("/sys/devices/virtual/block/bcache0/uevent",
>>>>> {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
>>>>> open("/sys/devices/virtual/block/bcache0/uevent", O_RDONLY|O_CLOEXEC) = 4
>>>>> read(4, "MAJOR=252\nMINOR=0\nDEVNAME=bcache"..., 4096) = 47
>>>>> readlink("/sys/devices/virtual/block/bcache0/subsystem",
>>>>> "../../../../class/block"..., 1024) = 23
>>>>> read(4, "N:bcache0\nW:40\nI:580433490\n", 4096) = 27
>>>>> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
>>>>> stat("/sys/class/block/bcache0/dev", {st_mode=S_IFREG|0444,
>>>>> st_size=4096, ...}) = 0
>>>>> open("/sys/class/block/bcache0/dev", O_RDONLY) = 6
>>>>>
>>>>> dev05 ~ # cat pvcreate-strace.log | grep bcache
>>>>> execve("/sbin/pvcreate", ["pvcreate", "/dev/bcache0"], [/* 23 vars */]) = 0
>>>>> read(3, "strace\0pvcreate\0/dev/bcache0\0", 31) = 29
>>>>> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
>>>>> readlink("/sys/dev/block/252:0",
>>>>> "../../devices/virtual/block/bcache0", 1024) = 35
>>>>> stat("/sys/devices/virtual/block/bcache0/uevent",
>>>>> {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
>>>>> stat("/sys/class/block/bcache0/dev", {st_mode=S_IFREG|0444,
>>>>> st_size=4096, ...}) = 0
>>>>> open("/sys/class/block/bcache0/dev", O_RDONLY) = 6
>>>>> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
>>>>> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
>>>>> stat("/sys/class/block/bcache0/dev", {st_mode=S_IFREG|0444,
>>>>> st_size=4096, ...}) = 0
>>>>> open("/sys/class/block/bcache0/dev", O_RDONLY) = 6
>>>>> write(2, "Device /dev/bcache0 not found (o"..., 56Device /dev/bcache0
>>>>> not found (or ignored by filtering).) = 56
>>>>>
>>>>> Kind regards,
>>>>> Joseph.
>>>>>
>>>>>
>>>>> On 2 March 2012 17:44, Kent Overstreet <kent.overstreet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>>> Oh - try stracing the pvcreate and see what happens.
>>>>>>
>>>>>> On Thu, Mar 1, 2012 at 10:03 PM, Kent Overstreet
>>>>>> <kent.overstreet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>>>> Weird.
>>>>>>>
>>>>>>> Did the /dev/bcache0 device get create created by udev?
>>>>>>>
>>>>>>> It's possible my code isn't poking the right thing. *mutters about the
>>>>>>> block layer...*
>>>>>>>
>>>>>>> On Thu, Mar 1, 2012 at 9:49 PM, Joseph Glanville
>>>>>>> <joseph.glanville-2MxvZkOi9dvvnOemgxGiVw@public.gmane.org> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I can't use bcache devices as members of lvm volume groups because
>>>>>>>> dmsetup can't find the devices.
>>>>>>>> It provides the ever useful feedback of:
>>>>>>>> # pvcreate /dev/bcache0
>>>>>>>>   Device /dev/bcache0 not found (or ignored by filtering).
>>>>>>>>
>>>>>>>> My LVM.conf is only filtering out nbd devices:
>>>>>>>> filter = [ "r|/dev/nbd.*|", "a/.*/" ]
>>>>>>>>
>>>>>>>> Any insight would be greatly appreciated. :)
>>>>>>>>
>>>>>>>> I also noted that bcache devices don't appear in iostat..
>>>>>>>>
>>>>>>>> Joseph.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Founder | Director | VP Research
>>>>>>>> Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
>>>>>>>> 99 52 | Mobile: 0428 754 846
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Founder | Director | VP Research
>>>>>>>> Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
>>>>>>>> 99 52 | Mobile: 0428 754 846
>>>>>>>> --
>>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>>>>>>>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Founder | Director | VP Research
>>>>> Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
>>>>> 99 52 | Mobile: 0428 754 846
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>>>>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>>
>>> --
>>> Founder | Director | VP Research
>>> Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
>>> 99 52 | Mobile: 0428 754 846
>
>
>
> --
> Founder | Director | VP Research
> Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
> 99 52 | Mobile: 0428 754 846

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [linux-lvm] bcache and dm targets (specifically lvm)
@ 2012-03-03  2:44                                     ` Kent Overstreet
  0 siblings, 0 replies; 16+ messages in thread
From: Kent Overstreet @ 2012-03-03  2:44 UTC (permalink / raw)
  To: Joseph Glanville; +Cc: linux-bcache, Kent Overstreet, linux-lvm

Oh, good! I thought it'd require a patch, that's much better.

On Fri, Mar 2, 2012 at 6:28 PM, Joseph Glanville
<joseph.glanville@orionvm.com.au> wrote:
> Ahh!
>
> I didn't know LVM had a device type lookup table. You can see if you
> look further that it also reads new types from the lvm.conf file.
> Adding this line to lvm.conf fixes the problem:
>
> types = [ "bcache", 16 ]
>
> I would imagine if merged it would be added to the internal compiled in table.
>
> Thanks for the pointer.
> Joseph.
>
> On 3 March 2012 13:17, Kent Overstreet <koverstreet@google.com> wrote:
>> I found the bug. Ugh...
>>
>> pvcreate refuses to use a device it doesn't recognize - look at the
>> lvm2 source, lib/filters/filter.c
>>
>> I don't know why and I don't think I want to know. I imagine it'd work
>> if you commented out the offending check (line 143 in my version).
>>
>> Maybe one of them can explain what's going on.
>>
>> On Fri, Mar 2, 2012 at 4:48 PM, Joseph Glanville
>> <joseph.glanville@orionvm.com.au> wrote:
>>> Cheers, I will try with a full disk device sometime later today.
>>>
>>> Thanks for you help,
>>> Joseph.
>>>
>>> On 3 March 2012 11:01, Kent Overstreet <koverstreet@google.com> wrote:
>>>> Strange, I don't see anything obvious in that log. Well, shouldn't be
>>>> too hard to track down, I'll see if I can reproduce it.
>>>>
>>>> On Fri, Mar 2, 2012 at 2:37 PM, Joseph Glanville
>>>> <joseph.glanville@orionvm.com.au> wrote:
>>>>> Hi Kent,
>>>>>
>>>>> The block device did indeed get created in /dev and the correct
>>>>> pointer exists in /sys/block/bcache0/dev
>>>>> I straced pvcreate and attached the outout, I couldn't see anything
>>>>> that far out of the ordinary though - bar the return that the device
>>>>> had been filtered.
>>>>> I am using commit f4c09286dd3f761310b24bc03e5ce95793a9a30c of
>>>>> bcache-tools.git and commit 7c3e597ca0f5c87767548d1e9aced024aa558b2a
>>>>> of linux-bcache.git
>>>>>
>>>>> The other thing I noticed was that the /dev/disk-by/uuid symlink
>>>>> wasn't created. I went ahead and created this myself but I will
>>>>> investigate why the udev rule didn't do this for me.
>>>>>
>>>>> Below is relevant lines from pvscan and pvcreate:
>>>>>
>>>>> dev05 ~ # cat pvscan.log | grep bcache
>>>>> execve("/sbin/pvscan", ["pvscan", "/dev/bcache0"], [/* 23 vars */]) = 0
>>>>> read(3, "strace\0pvscan\0/dev/bcache0\0", 31) = 27
>>>>> readlink("/sys/class/block/bcache0",
>>>>> "../../devices/virtual/block/bcache0"..., 1024) = 35
>>>>> stat("/sys/devices/virtual/block/bcache0/uevent",
>>>>> {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
>>>>> readlink("/sys/devices/virtual/block/bcache0", 0x7fff9e17aea0, 1024) =
>>>>> -1 EINVAL (Invalid argument)
>>>>> stat("/sys/devices/virtual/block/bcache0/uevent",
>>>>> {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
>>>>> open("/sys/devices/virtual/block/bcache0/uevent", O_RDONLY|O_CLOEXEC) = 4
>>>>> read(4, "MAJOR=252\nMINOR=0\nDEVNAME=bcache"..., 4096) = 47
>>>>> readlink("/sys/devices/virtual/block/bcache0/subsystem",
>>>>> "../../../../class/block"..., 1024) = 23
>>>>> read(4, "N:bcache0\nW:40\nI:580433490\n", 4096) = 27
>>>>> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
>>>>> stat("/sys/class/block/bcache0/dev", {st_mode=S_IFREG|0444,
>>>>> st_size=4096, ...}) = 0
>>>>> open("/sys/class/block/bcache0/dev", O_RDONLY) = 6
>>>>>
>>>>> dev05 ~ # cat pvcreate-strace.log | grep bcache
>>>>> execve("/sbin/pvcreate", ["pvcreate", "/dev/bcache0"], [/* 23 vars */]) = 0
>>>>> read(3, "strace\0pvcreate\0/dev/bcache0\0", 31) = 29
>>>>> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
>>>>> readlink("/sys/dev/block/252:0",
>>>>> "../../devices/virtual/block/bcache0", 1024) = 35
>>>>> stat("/sys/devices/virtual/block/bcache0/uevent",
>>>>> {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
>>>>> stat("/sys/class/block/bcache0/dev", {st_mode=S_IFREG|0444,
>>>>> st_size=4096, ...}) = 0
>>>>> open("/sys/class/block/bcache0/dev", O_RDONLY) = 6
>>>>> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
>>>>> stat("/dev/bcache0", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 0), ...}) = 0
>>>>> stat("/sys/class/block/bcache0/dev", {st_mode=S_IFREG|0444,
>>>>> st_size=4096, ...}) = 0
>>>>> open("/sys/class/block/bcache0/dev", O_RDONLY) = 6
>>>>> write(2, "Device /dev/bcache0 not found (o"..., 56Device /dev/bcache0
>>>>> not found (or ignored by filtering).) = 56
>>>>>
>>>>> Kind regards,
>>>>> Joseph.
>>>>>
>>>>>
>>>>> On 2 March 2012 17:44, Kent Overstreet <kent.overstreet@gmail.com> wrote:
>>>>>> Oh - try stracing the pvcreate and see what happens.
>>>>>>
>>>>>> On Thu, Mar 1, 2012 at 10:03 PM, Kent Overstreet
>>>>>> <kent.overstreet@gmail.com> wrote:
>>>>>>> Weird.
>>>>>>>
>>>>>>> Did the /dev/bcache0 device get create created by udev?
>>>>>>>
>>>>>>> It's possible my code isn't poking the right thing. *mutters about the
>>>>>>> block layer...*
>>>>>>>
>>>>>>> On Thu, Mar 1, 2012 at 9:49 PM, Joseph Glanville
>>>>>>> <joseph.glanville@orionvm.com.au> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I can't use bcache devices as members of lvm volume groups because
>>>>>>>> dmsetup can't find the devices.
>>>>>>>> It provides the ever useful feedback of:
>>>>>>>> # pvcreate /dev/bcache0
>>>>>>>> � Device /dev/bcache0 not found (or ignored by filtering).
>>>>>>>>
>>>>>>>> My LVM.conf is only filtering out nbd devices:
>>>>>>>> filter = [ "r|/dev/nbd.*|", "a/.*/" ]
>>>>>>>>
>>>>>>>> Any insight would be greatly appreciated. :)
>>>>>>>>
>>>>>>>> I also noted that bcache devices don't appear in iostat..
>>>>>>>>
>>>>>>>> Joseph.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Founder | Director | VP Research
>>>>>>>> Orion Virtualisation Solutions�|�www.orionvm.com.au�| Phone: 1300 56
>>>>>>>> 99 52 | Mobile: 0428 754 846
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Founder | Director | VP Research
>>>>>>>> Orion Virtualisation Solutions�|�www.orionvm.com.au�| Phone: 1300 56
>>>>>>>> 99 52 | Mobile: 0428 754 846
>>>>>>>> --
>>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>> More majordomo info at �http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Founder | Director | VP Research
>>>>> Orion Virtualisation Solutions�|�www.orionvm.com.au�| Phone: 1300 56
>>>>> 99 52 | Mobile: 0428 754 846
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at �http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>>
>>> --
>>> Founder | Director | VP Research
>>> Orion Virtualisation Solutions�|�www.orionvm.com.au�| Phone: 1300 56
>>> 99 52 | Mobile: 0428 754 846
>
>
>
> --
> Founder | Director | VP Research
> Orion Virtualisation Solutions�|�www.orionvm.com.au�| Phone: 1300 56
> 99 52 | Mobile: 0428 754 846

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: bcache and dm targets (specifically lvm)
  2012-03-03  2:28                                 ` [linux-lvm] " Joseph Glanville
@ 2012-03-04 14:21                                     ` Mike Snitzer
  -1 siblings, 0 replies; 16+ messages in thread
From: Mike Snitzer @ 2012-03-04 14:21 UTC (permalink / raw)
  To: Joseph Glanville
  Cc: Kent Overstreet, linux-bcache-u79uwXL29TY76Z2rM5mHXA,
	Kent Overstreet, linux-lvm-H+wXaHxf7aLQT0dZR+AlfA

On Fri, Mar 02 2012 at  9:28pm -0500,
Joseph Glanville <joseph.glanville-2MxvZkOi9dvvnOemgxGiVw@public.gmane.org> wrote:

> Ahh!
> 
> I didn't know LVM had a device type lookup table. You can see if you
> look further that it also reads new types from the lvm.conf file.
> Adding this line to lvm.conf fixes the problem:
> 
> types = [ "bcache", 16 ]
>
> I would imagine if merged it would be added to the internal compiled in table.

Assuming bcache devices are partitionable 16 would be used (like patch
below), if they aren't then 1 would be used.

Kent,

I know you were frustrated with DM in the past and that is why you
created your own device type.

I'll be looking much closer at bcache in the next week or so.  I'm
starting to work on a DM-based caching target... it will re-use the
drivers/md/persistent-data/ infrastructure we've established as part of
the DM Thin Provisioning target.

Anyway, even if bcache remains to be a standalone (non-DM) block device
in the future I'll have a look at it with an eye toward code sharing
that might allow other caching layers to build on a common layer.  Even
if the common code is a policy engine I think it'd be cool to allow
sharing of policy across caching targets.

That said I'm also open to porting bcache to DM... but time will tell.
I'll grab the latest bcache code and jump on the linux-bcache list and
we can take it one step at a time.

---
 lib/filters/filter.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/lib/filters/filter.c b/lib/filters/filter.c
index 4c3d3b7..f4a9615 100644
--- a/lib/filters/filter.c
+++ b/lib/filters/filter.c
@@ -129,6 +129,7 @@ static const device_info_t device_info[] = {
 	{"mmc", 16},		/* MMC block device */
 	{"blkext", 1},		/* Extended device partitions */
 	{"fio", 16},		/* Fusion */
+	{"bcache", 16},		/* bcache */
 	{NULL, 0}
 };
 

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* Re: [linux-lvm] bcache and dm targets (specifically lvm)
@ 2012-03-04 14:21                                     ` Mike Snitzer
  0 siblings, 0 replies; 16+ messages in thread
From: Mike Snitzer @ 2012-03-04 14:21 UTC (permalink / raw)
  To: Joseph Glanville
  Cc: Kent Overstreet, linux-lvm, linux-bcache, Kent Overstreet

On Fri, Mar 02 2012 at  9:28pm -0500,
Joseph Glanville <joseph.glanville@orionvm.com.au> wrote:

> Ahh!
> 
> I didn't know LVM had a device type lookup table. You can see if you
> look further that it also reads new types from the lvm.conf file.
> Adding this line to lvm.conf fixes the problem:
> 
> types = [ "bcache", 16 ]
>
> I would imagine if merged it would be added to the internal compiled in table.

Assuming bcache devices are partitionable 16 would be used (like patch
below), if they aren't then 1 would be used.

Kent,

I know you were frustrated with DM in the past and that is why you
created your own device type.

I'll be looking much closer at bcache in the next week or so.  I'm
starting to work on a DM-based caching target... it will re-use the
drivers/md/persistent-data/ infrastructure we've established as part of
the DM Thin Provisioning target.

Anyway, even if bcache remains to be a standalone (non-DM) block device
in the future I'll have a look at it with an eye toward code sharing
that might allow other caching layers to build on a common layer.  Even
if the common code is a policy engine I think it'd be cool to allow
sharing of policy across caching targets.

That said I'm also open to porting bcache to DM... but time will tell.
I'll grab the latest bcache code and jump on the linux-bcache list and
we can take it one step at a time.

---
 lib/filters/filter.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/lib/filters/filter.c b/lib/filters/filter.c
index 4c3d3b7..f4a9615 100644
--- a/lib/filters/filter.c
+++ b/lib/filters/filter.c
@@ -129,6 +129,7 @@ static const device_info_t device_info[] = {
 	{"mmc", 16},		/* MMC block device */
 	{"blkext", 1},		/* Extended device partitions */
 	{"fio", 16},		/* Fusion */
+	{"bcache", 16},		/* bcache */
 	{NULL, 0}
 };
 

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* Re: bcache and dm targets (specifically lvm)
  2012-03-04 14:21                                     ` [linux-lvm] " Mike Snitzer
@ 2012-03-06  7:03                                         ` Kent Overstreet
  -1 siblings, 0 replies; 16+ messages in thread
From: Kent Overstreet @ 2012-03-06  7:03 UTC (permalink / raw)
  To: Mike Snitzer
  Cc: Joseph Glanville, linux-bcache-u79uwXL29TY76Z2rM5mHXA,
	Kent Overstreet, linux-lvm-H+wXaHxf7aLQT0dZR+AlfA

On Sun, Mar 04, 2012 at 09:21:40AM -0500, Mike Snitzer wrote:
> On Fri, Mar 02 2012 at  9:28pm -0500,
> Joseph Glanville <joseph.glanville-2MxvZkOi9dvvnOemgxGiVw@public.gmane.org> wrote:
> 
> > Ahh!
> > 
> > I didn't know LVM had a device type lookup table. You can see if you
> > look further that it also reads new types from the lvm.conf file.
> > Adding this line to lvm.conf fixes the problem:
> > 
> > types = [ "bcache", 16 ]
> >
> > I would imagine if merged it would be added to the internal compiled in table.
> 
> Assuming bcache devices are partitionable 16 would be used (like patch
> below), if they aren't then 1 would be used.

Thanks... any insight into what that table is for?

> Kent,
> 
> I know you were frustrated with DM in the past and that is why you
> created your own device type.

That'd be accurate :)

> I'll be looking much closer at bcache in the next week or so.  I'm
> starting to work on a DM-based caching target... it will re-use the
> drivers/md/persistent-data/ infrastructure we've established as part of
> the DM Thin Provisioning target.

Interesting... I'm also working on thin provisioning in bcache. It's
functional now but not production ready, pending the copying garbage
collector which I'm working on now.

For now it'll only be suitable for flash though, as it uses the same
allocation code as the caching code and assumes efficient random reads.

> Anyway, even if bcache remains to be a standalone (non-DM) block device
> in the future I'll have a look at it with an eye toward code sharing
> that might allow other caching layers to build on a common layer.  Even
> if the common code is a policy engine I think it'd be cool to allow
> sharing of policy across caching targets.

I've been working on making bcache's b+tree and other code more modular
for building other things around it. It's gotten quite fast, capable of
somewhere north of a million lookups per second.

> That said I'm also open to porting bcache to DM... but time will tell.
> I'll grab the latest bcache code and jump on the linux-bcache list and
> we can take it one step at a time.

I'm not averse to a dm interface for bcache (though I don't really see
the usefulness myself)... I could definitely spend some time walking you
through code and improving documentation, if you're interested. 

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [linux-lvm] bcache and dm targets (specifically lvm)
@ 2012-03-06  7:03                                         ` Kent Overstreet
  0 siblings, 0 replies; 16+ messages in thread
From: Kent Overstreet @ 2012-03-06  7:03 UTC (permalink / raw)
  To: Mike Snitzer; +Cc: Joseph Glanville, linux-bcache, Kent Overstreet, linux-lvm

On Sun, Mar 04, 2012 at 09:21:40AM -0500, Mike Snitzer wrote:
> On Fri, Mar 02 2012 at  9:28pm -0500,
> Joseph Glanville <joseph.glanville@orionvm.com.au> wrote:
> 
> > Ahh!
> > 
> > I didn't know LVM had a device type lookup table. You can see if you
> > look further that it also reads new types from the lvm.conf file.
> > Adding this line to lvm.conf fixes the problem:
> > 
> > types = [ "bcache", 16 ]
> >
> > I would imagine if merged it would be added to the internal compiled in table.
> 
> Assuming bcache devices are partitionable 16 would be used (like patch
> below), if they aren't then 1 would be used.

Thanks... any insight into what that table is for?

> Kent,
> 
> I know you were frustrated with DM in the past and that is why you
> created your own device type.

That'd be accurate :)

> I'll be looking much closer at bcache in the next week or so.  I'm
> starting to work on a DM-based caching target... it will re-use the
> drivers/md/persistent-data/ infrastructure we've established as part of
> the DM Thin Provisioning target.

Interesting... I'm also working on thin provisioning in bcache. It's
functional now but not production ready, pending the copying garbage
collector which I'm working on now.

For now it'll only be suitable for flash though, as it uses the same
allocation code as the caching code and assumes efficient random reads.

> Anyway, even if bcache remains to be a standalone (non-DM) block device
> in the future I'll have a look at it with an eye toward code sharing
> that might allow other caching layers to build on a common layer.  Even
> if the common code is a policy engine I think it'd be cool to allow
> sharing of policy across caching targets.

I've been working on making bcache's b+tree and other code more modular
for building other things around it. It's gotten quite fast, capable of
somewhere north of a million lookups per second.

> That said I'm also open to porting bcache to DM... but time will tell.
> I'll grab the latest bcache code and jump on the linux-bcache list and
> we can take it one step at a time.

I'm not averse to a dm interface for bcache (though I don't really see
the usefulness myself)... I could definitely spend some time walking you
through code and improving documentation, if you're interested. 

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2012-03-06  7:03 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CAOzFzEjKapphA5NKCWbEyx4nvjWw+e_dxr+fOLr8f5j586jiyA@mail.gmail.com>
     [not found] ` <CAOzFzEjKapphA5NKCWbEyx4nvjWw+e_dxr+fOLr8f5j586jiyA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-03-02  5:49   ` Fwd: bcache and dm targets (specifically lvm) Joseph Glanville
     [not found]     ` <CAOzFzEjffLGjYhOznTo1F3moHLq+nvKYZFoy7mkU-q8RPDd9oQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-03-02  6:03       ` Kent Overstreet
     [not found]         ` <CAC7rs0vpQAaF9uNhhy2ziLa+3EB6udJVRjGwf=RVoSk0TxuDcw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-03-02  6:44           ` Kent Overstreet
     [not found]             ` <CAC7rs0us5Xqag_AWq=wsFYqn3Fub3qt59a9=vDeS5cLh2oOg0Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-03-02 22:37               ` Joseph Glanville
     [not found]                 ` <CAOzFzEifqyFz2G=0OEPA9BN8-kU3MabUhGmU7-jSQCxwPcHrpw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-03-03  0:01                   ` Kent Overstreet
     [not found]                     ` <CAH+dOx+eWJKvKz=HEGHaPu8tqqz2CqVjUC1+0GJqta0GE4aYNw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-03-03  0:48                       ` Joseph Glanville
     [not found]                         ` <CAOzFzEj=gBXL9UaVytrebU3gr2p1rJaMVPkz1X0oZOALQKbcNA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-03-03  2:17                           ` Kent Overstreet
2012-03-03  2:17                             ` [linux-lvm] " Kent Overstreet
     [not found]                             ` <CAH+dOxKznm_mhe_TkN5eOY8tz6snyAC0TF6bsZpi4P1KtDd9kA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-03-03  2:28                               ` Joseph Glanville
2012-03-03  2:28                                 ` [linux-lvm] " Joseph Glanville
     [not found]                                 ` <CAOzFzEiSR1izXGuS+djSpCJOTnaPU6KetR=wB8tXmPopUk4Jrg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-03-03  2:44                                   ` Kent Overstreet
2012-03-03  2:44                                     ` [linux-lvm] " Kent Overstreet
2012-03-04 14:21                                   ` Mike Snitzer
2012-03-04 14:21                                     ` [linux-lvm] " Mike Snitzer
     [not found]                                     ` <20120304142139.GA10510-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-03-06  7:03                                       ` Kent Overstreet
2012-03-06  7:03                                         ` [linux-lvm] " Kent Overstreet

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.