Hide Forgot
Description of problem: mkfs.btrfs ignored --alloc-start option Version-Release number of selected component (if applicable): btrfs-progs-3.12-1.fc20.x86_64 How reproducible: dd if=/dev/zero of=fs.img bs=1M count=1K; sync mkfs.btrfs -L Test --alloc-start 536870912 fs.img mkdir /mnt/test mount -o loop,offset=536870912 fs.img /mnt/test I get an error message: mount: /dev/loop0 is write-protected, mounting read-only mount: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. But: dd if=/dev/zero of=fs0.img bs=1M count=512 dd if=/dev/zero of=fs1.img bs=1M count=512; sync mkfs.btrfs -L Test fs1.img cat fs0.img fs1.img >fs.img; sync mount -o loop,offset=536870912 fs.img /mnt/test This version work. Actual results: Ignored -A option, no offset.
btrfs-progs-3.14.1 has been pushed to Fedora 19 and 20 for testing. I frankly have no idea if this will resolve your bug or not, but if you test it and find that it does, please take the opportunity to close this bug. :) Thanks, -Eric
I don't think this option does what you think it does, sadly. From the commit message back in 2008: Add mkfs.btrfs -A offset to control allocation start on devices This is a utility option for the resizer, it makes sure to allocate at offset bytes in the disk or higher. It ensures the resizer will have something to move when testing it. So this simply starts *allocating* at that point, but does not start the filesystem at this point. The manpage is not clear about this: -A, --alloc-start offset Specify the offset from the start of the device to start the btrfs filesystem. The default value is zero, or the start of the device. It's not the start of the fileysystem; it's where the filesystem will start new allocations. A manpage update is probably in order.
I sent a patch for the manpage upstream, hopefully chris or dave will pick it up.