filesystem seeding ... BUGs on .38, .39, loopback, real devices, tmp branch ... everything
hello, i'm trying to setup a seeded FS -- was only able to find this: http://thread.gmane.org/gmane.comp.file-systems.btrfs/10529 ... and announcement-like info from 2009 or so. i keep hitting bugs/oops, and even though the FS *appears* to work correctly afterwards, sometimes mount/strace/etc will hang (could only be .38 here). i tried with loop devices at first, then real devices -- this is all under KVM/QEMU, and with FSs that are/will be smaller than 1G. i've tried with .38, .39, mixed blocks groups, the `tmp` branch from btrfs-progs, and everything else i can think of ... what am i doing wrong? are these known problems (per the other thread ...)? what is the correct way to seed a filesystem? `btrfs filesystem show` reports the FS as missing a device ... but it seems to mount fine. the operation appears to spawn a whole new FS with the same label -- would anyone mind elaborating more? i used the --rootdir feature of mkfs.btrfs to populate the image with ~100MB of barebone filesystem. the `mtime` of the seeded image never changes, so it *seems* to be working ... but i dont understand how to reuse this image or what's really going on (per my above questions :-). ... procedures follow along with the oops it produces; let me know what, if anything, else i should try. i get similar results no matter what i attempt, so i only included the one for now. thanks, C Anthony 2.6.39, loopback, `tmp` branch - #!/bin/bash mkdir ro rw truncate -s700MB output.img.rw mkfs.btrfs -M -r /root/btrfs/fs -m raid0 -d raid0 -L _btrfs_ro_seed btrfstune -S1 output.img losetup /dev/loop0 output.img losetup /dev/loop1 output.img.rw mount /dev/loop0 ro btrfs device add /dev/loop1 ro # !!! BUG !!! mount /dev/loop1 rw echo there ro/hi # FAILS: Read-only filesystem echo there rw/hi # SEEMS TO WORK ... - # btrfs filesystem show - Label: '_btrfs_ro_seed' uuid: 1f29a49c-e437-4329-ac81-d50adea03688 Total devices 1 FS bytes used 97.29MB devid1 size 256.00MB used 169.96MB path /dev/loop0 Label: '_btrfs_ro_seed' uuid: 5824e2ce-6008-4d6d-8e1a-a5b6621214ac Total devices 2 FS bytes used 97.29MB devid2 size 667.57MB used 82.75MB path /dev/loop1 *** Some devices missing Btrfs v0.19-50-ge6bd18d-dirty - START OOPS - [ 2808.826972] device label _btrfs_ro_seed devid 1 transid 13 /dev/loop0 [ 2808.832205] device label _btrfs_ro_seed devid 1 transid 13 /dev/loop0 [ 2808.834058] btrfs: disk space caching is enabled [ 2808.906916] [ cut here ] [ 2808.907673] WARNING: at fs/btrfs/extent-tree.c:5790 btrfs_alloc_free_block+0x1ec/0x330 [btrfs]() [ 2808.908981] Hardware name: Bochs [ 2808.909604] Modules linked in: btrfs zlib_deflate crc32c libcrc32c loop ipv6 ext2 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer snd uhci_hcd i2c_piix4 psmouse floppy ehci_hcd processor soundcore snd_page_alloc pcspkr evdev button usbcore serio_raw sg i2c_core ext4 mbcache jbd2 crc16 sr_mod cdrom pata_acpi ata_piix libata scsi_mod virtio_rng virtio_pci virtio_net virtio_console virtio_blk virtio_balloon virtio_ring virtio [ 2808.920256] Pid: 2695, comm: btrfs Tainted: G D W 2.6.39-ARCH #1 [ 2808.921097] Call Trace: [ 2808.921724] [810577da] warn_slowpath_common+0x7a/0xb0 [ 2808.922532] [81057825] warn_slowpath_null+0x15/0x20 [ 2808.923371] [a036c74c] btrfs_alloc_free_block+0x1ec/0x330 [btrfs] [ 2808.924257] [a039f337] ? read_extent_buffer+0xd7/0x1e0 [btrfs] [ 2808.925134] [a0358d19] __btrfs_cow_block+0x159/0x890 [btrfs] [ 2808.925992] [a0359563] btrfs_cow_block+0x113/0x350 [btrfs] [ 2808.926863] [a035ef82] btrfs_search_slot+0x1d2/0x9f0 [btrfs] [ 2808.927736] [a039a202] ? free_extent_state+0x32/0x50 [btrfs] [ 2808.928589] [a0360930] btrfs_insert_empty_items+0x70/0xd0 [btrfs] [ 2808.929455] [a03609f0] btrfs_insert_item+0x60/0xe0 [btrfs] [ 2808.930323] [a036e40c] btrfs_make_block_group+0x25c/0x2d0 [btrfs] [ 2808.931204] [a03a41c4] __btrfs_alloc_chunk+0x524/0x970 [btrfs] [ 2808.932083] [a03a4874] init_first_rw_device+0x74/0x130 [btrfs] [ 2808.932945] [813c95a9] ? __mutex_lock_slowpath+0x239/0x320 [ 2808.933805] [a03a6512] btrfs_init_new_device+0x642/0xcd0 [btrfs] [ 2808.934669] [a03ac128] ? btrfs_ioctl+0x7c8/0xa20 [btrfs] [ 2808.935519] [a03ac14a] btrfs_ioctl+0x7ea/0xa20 [btrfs] [ 2808.936328] [81174d8e] ? __blkdev_put+0x1ee/0x200 [ 2808.937151] [8115264e] do_vfs_ioctl+0x8e/0x500 [ 2808.937938] [8115ec2a] ? mntput+0x1a/0x30 [ 2808.938710] [81142927] ? fput+0x167/0x210 [ 2808.939458] [81152b51] sys_ioctl+0x91/0xa0 [ 2808.940236] [813cb312]
Re: filesystem seeding ... BUGs on .38, .39, loopback, real devices, tmp branch ... everything
On Thu, 2011-06-02 at 04:20 -0500, C Anthony Risinger wrote: i tried with loop devices at first, then real devices -- this is all under KVM/QEMU, and with FSs that are/will be smaller than 1G. I have tried the seed option as well. I was able to successfully mount the read write partition after setting up the seed. However, both had to be independent partitions on a real device. During testing, both .38 and .39rc could NOT create a seed if one or both partitions were encrypted. I believe encrypted partitions also work with a loop device for the unlocked version you write too. The response I got after a few days is as follows: Chris Mason chris.ma...@oracle.com cwillu cwi...@cwillu.com date Thu, May 5, 2011 at 4:42 PM Ok, looks like I busted the seed support when I fixed up some of the chunk allocations. I'll reproduce this and work out a fix. I just assumed it would take a while to fix so I haven't tried again since. If the root of the problem appears to be loop devices, you might want to report that. Err I guess you did. To me, this doesn't explain why it wouldn't work in a Virtual Machine. I would have thought the VM would treat it as a real device. -- 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
Re: filesystem seeding ... BUGs on .38, .39, loopback, real devices, tmp branch ... everything
On Thu, Jun 2, 2011 at 6:40 AM, Geoff Ritter geoff.rit...@gmail.com wrote: On Thu, 2011-06-02 at 04:20 -0500, C Anthony Risinger wrote: i tried with loop devices at first, then real devices -- this is all under KVM/QEMU, and with FSs that are/will be smaller than 1G. I have tried the seed option as well. I was able to successfully mount the read write partition after setting up the seed. However, both had to be independent partitions on a real device. During testing, both .38 and .39rc could NOT create a seed if one or both partitions were encrypted. I believe encrypted partitions also work with a loop device for the unlocked version you write too. The response I got after a few days is as follows: Chris Mason chris.ma...@oracle.com cwillu cwi...@cwillu.com date Thu, May 5, 2011 at 4:42 PM Ok, looks like I busted the seed support when I fixed up some of the chunk allocations. I'll reproduce this and work out a fix. I just assumed it would take a while to fix so I haven't tried again since. If the root of the problem appears to be loop devices, you might want to report that. Err I guess you did. To me, this doesn't explain why it wouldn't work in a Virtual Machine. I would have thought the VM would treat it as a real device. yeah ... i wasn't sure if this was the same exact problem you had or what, i can't find much info at all about anyone using seed support. i tried loop devices on my real machine too (.38), and because of continuous oops/locks i moved to a VM so i didn't hose my system. however, when i tried with real devices in the VM, these were not loopbacks, they were just regular raw files used as backing for QEMU (though i don't know if it internally uses loopback) ... they were exposed as virtio devices /dev/vdb and /dev/vdc. i got the exact same results using those devices, using btrfs-vol instead of btrfs, and a whole slew of other trial and error that all led to the same issue. the 10 lines or so i provided earlier reproduces consistently for me ... in the end, it *seemed* to work, but still :-) what i REALLY want though, is simply more information on how seeding works and should be used ... the wiki et al seem to imply that i can reuse the seed device for MULTIPLE filesystems ... how can i do this? i tried adding the device to an existing array but i couldnt see any files ... can anyone shed some light on this feature? thanks much, C Anthony -- 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
