Bug 1037852

Summary: mkfs.btrfs ignored --alloc-start option
Product: [Fedora] Fedora Reporter: rvcsaba
Component: btrfs-progsAssignee: Josef Bacik <josef>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: esandeen, josef, mmahut
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-05-13 22:26:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description rvcsaba 2013-12-03 22:31:37 UTC
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.

Comment 1 Eric Sandeen 2014-05-13 16:39:05 UTC
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

Comment 2 Eric Sandeen 2014-05-13 16:42:55 UTC
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.

Comment 3 Eric Sandeen 2014-05-13 22:26:33 UTC
I sent a patch for the manpage upstream, hopefully chris or dave will pick it up.