make btrfs-image work

RFC In review Josef Bacik 2 participants 3 messages Jan 19, 2010 – Jan 20, 2010 Btrfs file system

lore

Share & tools

lore

Josef Bacik

author

2010-01-19 16:04 UTC #0 lore raw

RFC 1/1 make btrfs-image work

Hello,

btrfs-image would be very helpful for debugging some users problems that we can't reproduce ourselves, but every image that i try and re-create with btrfs-image makes btrfs panic. This is because we zero out the superblocks chunk array and re-create our uuid. This means that we end up not being able to read the chunk tree on mount, and then even if we could the uuid's of the metadata we read back wouldn't match the uuid of the device. The way I've fixed this is to just spit the metadata back onto the disk exactly the way we got it. The caveat to this I think is that if we try to image a multi-device setup that it won't work right unless we have a multi-device setup to restore the image onto. I'm not sure if thats the goal or not. This patch makes the single disk case work fine for me. Let me know what you think. Thanks,

Josef

btrfs-image.c +0 ~~-38~~

index f2bbcc8..2d45ac3 100644
@@ -564,41 +564,6 @@ static int create_metadump(const char *input, FILE *out, int num_threads,
 	return 0;
 }
 
-static void update_super(u8 *buffer)
-{
-	struct btrfs_super_block *super = (struct btrfs_super_block *)buffer;
-	struct btrfs_chunk *chunk;
-	struct btrfs_disk_key *key;
-	u32 sectorsize = btrfs_super_sectorsize(super);
-	u64 flags = btrfs_super_flags(super);
-
-	flags |= BTRFS_SUPER_FLAG_METADUMP;
-	btrfs_set_super_flags(super, flags);
-
-	key = (struct btrfs_disk_key *)(super->sys_chunk_array);
-	chunk = (struct btrfs_chunk *)(super->sys_chunk_array +
-				       sizeof(struct btrfs_disk_key));
-
-	btrfs_set_disk_key_objectid(key, BTRFS_FIRST_CHUNK_TREE_OBJECTID);
-	btrfs_set_disk_key_type(key, BTRFS_CHUNK_ITEM_KEY);
-	btrfs_set_disk_key_offset(key, 0);
-
-	btrfs_set_stack_chunk_length(chunk, (u64)-1);
-	btrfs_set_stack_chunk_owner(chunk, BTRFS_EXTENT_TREE_OBJECTID);
-	btrfs_set_stack_chunk_stripe_len(chunk, 64 * 1024);
-	btrfs_set_stack_chunk_type(chunk, BTRFS_BLOCK_GROUP_SYSTEM);
-	btrfs_set_stack_chunk_io_align(chunk, sectorsize);
-	btrfs_set_stack_chunk_io_width(chunk, sectorsize);
-	btrfs_set_stack_chunk_sector_size(chunk, sectorsize);
-	btrfs_set_stack_chunk_num_stripes(chunk, 1);
-	btrfs_set_stack_chunk_sub_stripes(chunk, 0);
-	chunk->stripe.devid = super->dev_item.devid;
-	chunk->stripe.offset = cpu_to_le64(0);
-	memcpy(chunk->stripe.dev_uuid, super->dev_item.uuid, BTRFS_UUID_SIZE);
-	btrfs_set_super_sys_array_size(super, sizeof(*key) + sizeof(*chunk));
-	csum_block(buffer, 4096);
-}
-
 static void *restore_worker(void *data)
 {
 	struct mdrestore_struct *mdres = (struct mdrestore_struct *)data;

@@ -637,9 +602,6 @@ static void *restore_worker(void *data)
 			size = async->bufsize;
 		}
 
-		if (async->start == BTRFS_SUPER_INFO_OFFSET)
-			update_super(outbuf);
-
 		ret = pwrite64(outfd, outbuf, size, async->start);
 		BUG_ON(ret != size);

Yan, Zheng

2010-01-20 02:28 UTC #1 lore raw

Quoted 3 lines · Josef Bacik

Hello,
btrfs-image would be very helpful for debugging some users problems t=

hat we

Quoted 1 line

can't reproduce ourselves, but every image that i try and re-create w=

ith

Quoted 1 line

btrfs-image makes btrfs panic. =A0This is because we zero out the sup=

erblocks

Quoted 1 line

chunk array and re-create our uuid. =A0This means that we end up not =

being able to

Quoted 1 line

read the chunk tree on mount, and then even if we could the uuid's of=

the

Quoted 1 line

metadata we read back wouldn't match the uuid of the device. =A0The w=

ay I've fixed

Quoted 1 line

this is to just spit the metadata back onto the disk exactly the way =

we got it.

Quoted 1 line

The caveat to this I think is that if we try to image a multi-device =

setup that

Quoted 1 line

it won't work right unless we have a multi-device setup to restore th=

e image

Quoted 1 line

onto. =A0I'm not sure if thats the goal or not. =A0This patch makes t=

he single disk

Quoted 2 lines

case work fine for me. =A0Let me know what you think. =A0Thanks,

The goal of btrfs-image is create image that can be examined by btrfsc= k and
btrfs-debug-tree. btrfs-image creates metadata image for btrfs' logical=
address
space. So your patch only works for the uncommon case that btrfs' logic= al
address is mapped to offset of device.

Yan, Zheng
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Josef Bacik

author

2010-01-20 02:37 UTC #2 lore raw

Quoted 1 line · Zheng

On Wed, Jan 20, 2010 at 12:04 AM, Josef Bacik <[email protected]> wrot=

Quoted 3 lines

Quoted 3 lines
Hello,
btrfs-image would be very helpful for debugging some users problems=

that we

Quoted 1 line

Quoted 1 line
can't reproduce ourselves, but every image that i try and re-create=

with

Quoted 1 line

Quoted 1 line
btrfs-image makes btrfs panic. =A0This is because we zero out the s=

uperblocks

Quoted 1 line

Quoted 1 line
chunk array and re-create our uuid. =A0This means that we end up no=

t being able to

Quoted 1 line

Quoted 1 line
read the chunk tree on mount, and then even if we could the uuid's =

of the

Quoted 1 line

Quoted 1 line
metadata we read back wouldn't match the uuid of the device. =A0The=

way I've fixed

Quoted 1 line

Quoted 1 line
this is to just spit the metadata back onto the disk exactly the wa=

y we got it.

Quoted 1 line

Quoted 1 line
The caveat to this I think is that if we try to image a multi-devic=

e setup that

Quoted 1 line

Quoted 1 line
it won't work right unless we have a multi-device setup to restore =

the image

Quoted 1 line

Quoted 1 line
onto. =A0I'm not sure if thats the goal or not. =A0This patch makes=

the single disk

Quoted 4 lines

Quoted 2 lines
case work fine for me. =A0Let me know what you think. =A0Thanks,
=20
The goal of btrfs-image is create image that can be examined by btrf=

sck and

Quoted 1 line

btrfs-debug-tree. btrfs-image creates metadata image for btrfs' logic=

al address

Quoted 1 line

space. So your patch only works for the uncommon case that btrfs' log=

ical

Quoted 2 lines

address is mapped to offset of device.
=20

Ok, but I think it would be helpful to be able to restore the fs onto a=
device
and still be able to use it like a normal fs so we can debug other type= s of
problems. But I don't really care that much so if that wasn't the inte= nded goal
I'll find something else to work on. Thanks,

Josef
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html