* Re: [linux-lvm] bcache and dm targets (specifically lvm) [not found] ` <CAOzFzEj=gBXL9UaVytrebU3gr2p1rJaMVPkz1X0oZOALQKbcNA@mail.gmail.com> @ 2012-03-03 2:17 ` Kent Overstreet 2012-03-03 2:28 ` Joseph Glanville 0 siblings, 1 reply; 5+ 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] 5+ messages in thread
* Re: [linux-lvm] bcache and dm targets (specifically lvm) 2012-03-03 2:17 ` [linux-lvm] bcache and dm targets (specifically lvm) Kent Overstreet @ 2012-03-03 2:28 ` Joseph Glanville 2012-03-03 2:44 ` Kent Overstreet 2012-03-04 14:21 ` Mike Snitzer 0 siblings, 2 replies; 5+ 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] 5+ messages in thread
* Re: [linux-lvm] bcache and dm targets (specifically lvm) 2012-03-03 2:28 ` Joseph Glanville @ 2012-03-03 2:44 ` Kent Overstreet 2012-03-04 14:21 ` Mike Snitzer 1 sibling, 0 replies; 5+ 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] 5+ messages in thread
* Re: [linux-lvm] bcache and dm targets (specifically lvm) 2012-03-03 2:28 ` Joseph Glanville 2012-03-03 2:44 ` Kent Overstreet @ 2012-03-04 14:21 ` Mike Snitzer 2012-03-06 7:03 ` Kent Overstreet 1 sibling, 1 reply; 5+ 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] 5+ messages in thread
* Re: [linux-lvm] bcache and dm targets (specifically lvm) 2012-03-04 14:21 ` Mike Snitzer @ 2012-03-06 7:03 ` Kent Overstreet 0 siblings, 0 replies; 5+ 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] 5+ messages in thread
end of thread, other threads:[~2012-03-06 7:03 UTC | newest]
Thread overview: 5+ 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] ` <CAOzFzEjffLGjYhOznTo1F3moHLq+nvKYZFoy7mkU-q8RPDd9oQ@mail.gmail.com>
[not found] ` <CAC7rs0vpQAaF9uNhhy2ziLa+3EB6udJVRjGwf=RVoSk0TxuDcw@mail.gmail.com>
[not found] ` <CAC7rs0us5Xqag_AWq=wsFYqn3Fub3qt59a9=vDeS5cLh2oOg0Q@mail.gmail.com>
[not found] ` <CAOzFzEifqyFz2G=0OEPA9BN8-kU3MabUhGmU7-jSQCxwPcHrpw@mail.gmail.com>
[not found] ` <CAH+dOx+eWJKvKz=HEGHaPu8tqqz2CqVjUC1+0GJqta0GE4aYNw@mail.gmail.com>
[not found] ` <CAOzFzEj=gBXL9UaVytrebU3gr2p1rJaMVPkz1X0oZOALQKbcNA@mail.gmail.com>
2012-03-03 2:17 ` [linux-lvm] bcache and dm targets (specifically lvm) Kent Overstreet
2012-03-03 2:28 ` Joseph Glanville
2012-03-03 2:44 ` Kent Overstreet
2012-03-04 14:21 ` Mike Snitzer
2012-03-06 7:03 ` Kent Overstreet
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).