On Thu, Sep 30, 2010 at 21:48, Josef Bacik <josef@xxxxxxxxxx> wrote: > On Wed, Sep 29, 2010 at 07:43:27PM -0400, Christoph Hellwig wrote: >> On Wed, Sep 29, 2010 at 10:04:31AM +0200, Kay Sievers wrote: >> > On Wed, Sep 29, 2010 at 09:25, Ric Wheeler <rwheeler@xxxxxxxxxx> wrote: >> > >> > > Second question is why is checking in /sys a big deal, would ??you prefer an >> > > interface like we did for alignment in libblkid? >> > >> > It's about knowing what's behind the 'nodev' major == 0 of a btrfs >> > mount. There is no way to get that from /sys or anywhere else at the >> > moment. >> > >> > Usually filesystems backed by a disk have the dev_t of the device, or >> > the fake block devices like md/dm/raid have their own major and the >> > slaves/ directory pointing to the devices. >> > >> > This is not only about readahead, it's every other tool, that needs to >> > know what kind of disks are behind a btrfs 'nodev' major == 0 mount. >> >> Thanks for explaining the problem. ÂIt's one that affects everything >> with more than one underlying block device, so adding a >> filesystem-specific ioctl hack is not a good idea. ÂAs mentioned in this >> mail we already have a solution for that - the block device slaves >> links used for raid and volume managers. ÂThe most logical fix is to >> re-use that for btrfs as well and stop it from abusing the anonymous >> block major that was never intended for block based filesystems (and >> already has caused trouble in other areas). ÂOne way to to this might >> be to allocate a block major for btrfs that only gets used for >> representing these links. >> > > Ok I've spent a few hours on this and I'm hitting a wall. ÂIn order to get the > sort of /sys/block/btrfs-# sort of thing I have to do > > 1) register_blkdev to get a major > 2) setup a gendisk > 3) do a bdget_disk > 4) Loop through all of our devices and do a bd_claim_by_disk on each of them > > This sucks because for step #2 I have to have a request_queue for the disk. > It's a bogus disk, and theres no way to not have a request_queue, so I'd have to > wire that up and put a bunch of WARN_ON()'s to make sure nobody is trying to > write to our special disk (since I assume that if I go through all this crap I'm > going to end up with a /dev/btrfs-# that people are going to try to write to). > > So my question is, is this what we want? ÂDo I just need to quit bitching and > make it work? ÂOr am I doing something wrong? ÂThis is a completely new area for > me so I'm just looking around at what md/dm does and trying to mirror it for my > own uses, if thats not what I should be doing please tell me, otherwise this > seems like alot of work for a very shitty solution to our problem. ÂThanks, Yeah, that matches what I was experiencing when thinking about the options. Making a btrfs mount a fake blockdev of zero size seems like a pretty weird hack, just get some 'dead' directories in sysfs. A btrfs mount is just not a raw blockdev, and should probably not pretend to be one. I guess a statfs()-like call from the filesystem side and not the block side, which can put out such information in some generic way, would better fit here. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
