On Thu, May 09, 2013 at 08:54:14PM +0100, Roger Leigh wrote: > On Thu, May 09, 2013 at 09:01:49AM -0700, George Mitchell wrote: > > Karel, Your answer left me really frustrated, but after rethinking > > the whole thing, I am left wondering if this whole issue, including > > the broader issue of what should appear on the mount table in the > > first place, would be better addressed by the btrfs group simply > > abstracting the mount point like software raid has always done and > > handling all the details internally within btrfs. I already have > > seen applications that didn't understand btrfs partitions were in > > use and bad things could result from that. It would be nice if > > btrfs would just lock all of these partitions out and represent them > > collectively to the broader system as /dev/mntX or whatever. That > > would surely greatly simplify things for everybody. I am going > > broach that idea on the btrfs list. > > If you do bring this up on the list, a related problem that breaks > a number of tools, and also boot-time fsck on Debian systems, is > that the device reported by stat(2) st_rdev is fictional and not > present in /dev. This is probably because every subvolume has a > different device ID. But it's not exposed to userspace. Good point, this is the worst thing I don't like on btrfs. https://bugzilla.redhat.com/show_bug.cgi?id=711881 Karel -- Karel Zak <kzak@xxxxxxxxxx> http://karelzak.blogspot.com -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
