On 1 February 2012 03:04, infernix <infernix@xxxxxxxxxxxx> wrote: > Op 31-1-2012 16:50, Joseph Glanville schreef: > >>> I've got the following stack, bottom to top: >>> - iscsi sans with multiple NICs >>> - servers with multiple NICs >>> - open-iscsi cross-connecting to the san over those multiple nics >>> - multipath to aggregate and load-balance IO over said paths >>> - LVM on top of multiple mpathX devices >>> - qemu-kvm running with disks connecting to logical volumes in said LVM > > >> If you are bottlenecking purely on random I/O then the easiest and >> most logical place for bcache is infront of your iSCSI backing store >> on your SAN. > > > Agreed. But since the SAN is proprietary, there's zero chance of > implementing bcache on the SAN :) Ahh the wonders of proprietary appliances. :P > > >> If however you are bottlenecked on the iSCSI interconnect you could >> feasibly place bcache ontop of the multipath devices (they are just >> standard dm targets) right below the VMs. >> This adds the highest possible amount of performance to the VMs at the >> cost of increased maintaince, complexity of multiple caches and >> ofcourse cost. > > > Yes. So that is why I think the tradeoff of putting bcache on the mpath > devices is the best. There's no shared storage use between servers; each > just uses its own LVs. As long as I'm using writethrough, this is safe. > Doing writeback is simply impossible with multiple caches like this. It's actually quite easy to script, you can use SCSI ID or similar to map the LUNs or LVs (not sure how you have things setup) to block paths, which you can then use with multipath -ll to get the multipath WWID I'm playing with something similar atm. > > Setting up bcache for each and every logical volume is not really going to > work because they are quite dynamic. > > >>> Is there any other way of activating bcache besides passing it an UUID? >>> And >>> can it even work on top of a dm-multipath device? >> >> >> It works on LVM so it should work fine on multipath targets too. > > > Except that I can't get an UUID from the LVM PVs: > > blkid /dev/mpath/mpath2 -s UUID -o value That is a very valid point.. bcache should probably index by something other than UUID because most block devices don't have them.. only filesystems.. > > Returns nothing. So I'm a little confused as to how to register the device > for caching. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-bcache" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
