On Wed, Jul 15, 2015 at 09:45:17AM -0600, Chris Murphy wrote: > On Wed, Jul 15, 2015 at 5:07 AM, Austin S Hemmelgarn > <ahferro...@gmail.com> wrote: > > I've managed to get the other filesystems I was having issues with mounted > > again with the device= options and clear_cache after running btrfs dev scan > > a couple of times. It seems to me (at least from what I'm seeing) that > > there is some metadata that isn't synchronized properly between the disks. > > OK see if this logic follows without mistakes: > > The fs metadata is raid6, and therefore is broken up across all > drives. Since you successfully captured an image of the file system > with btrfs-image, clearly user space tool is finding a minimum of n-2 > drives. If it didn't complain of missing drives, it found n drives. > > And yet the kernel is not finding n drives. And even with degraded it > still won't mount, therefore it's not finding n-2 drives. > > By "drives" I mean either the physical device, or more likely whatever > minimal metadata is necessary for "assembling" all devices into a > volume. I don't know what that nugget of information is that's on each > physical device, separate from the superblocks (which I think is > distributed at logical addresses and therefore not on every physical > drive), and if we have any tools to extract just that and debug it.
There is at least one superblock on every device, usually two, and often three. Each superblock contains the virtual address of the roots of the root tree, the chunk tree and the log tree. Those are useless without having the chunk tree, so there's also some information about the chunk tree appended to the end of each superblock to bootstrap the virtual address space lookup. The information at the end of the superblock seems to be a list of packed (key, struct btrfs_chunk) pairs for the System chunks. The struct btrfs_chunk contains info about the chunk as a whole, and each stripe making it up. The stripe information is a devid, an offset (presumably in physical address on the device), and a UUID. So, from btrfs dev scan the kernel has all the devid to (major, minor) mappings for devices. From one device, it reads a superblock, gets the list of (devid, offset) for the System chunks at the end of that superblock, and can then identify the location of the System chunks to read the full chunk tree. Once it's got the chunk tree, it can do virtual->physical lookups, and the root tree and log tree locations make sense. I don't know whether btrfs-image works any differently from that, or if so, how it differs. Hugo. -- Hugo Mills | Radio is superior to television: the pictures are hugo@... carfax.org.uk | better http://carfax.org.uk/ | PGP: E2AB1DE4 |
signature.asc
Description: Digital signature
