On Thu, Sep 30, 2010 at 09:43:00AM +0200, Kay Sievers wrote: > On Thu, Sep 30, 2010 at 01:43, Christoph Hellwig <h...@infradead.org> wrote: > > On Wed, Sep 29, 2010 at 10:04:31AM +0200, Kay Sievers wrote: > >> On Wed, Sep 29, 2010 at 09:25, Ric Wheeler <rwhee...@redhat.com> 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. > > Yeah, we thought about that too, but a btrfs mount does not show up as > a block device, like md/dm, so there is no place for a slaves/ > directory in /sys with the individual disks listed. How could be solve > that? Create some fake blockdev for every btrfs mount, but that can't > be used to read/write raw blocks? >
That's what I was going to do. We essentially do that anyway with the anonymous superblock, so instead I'll just make /dev/btrfs-# whatever and do the bd_claim_by_disk stuff to make all of our devices slaves of that parent virtual device. Does this seem like a resonable solution? Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
