mkfs devices ordering relevant with devices of different sizes?

mkfs devices ordering relevant with devices of different sizes?

[Cyril B.]

Hello,

When creating a filesystem with devices of different sizes, the resulting 
filesystem total size depends on the device order specified to mkfs. When 
the smaller device is specified first, the second (larger) device is seen as 
the same size as the first. This doesn't occur when the order is reversed.

It's confusing. Is this expected? I'm using the latest btrfs-progs and Linux 
3.5.


# ./mkfs.btrfs /dev/sda4 /dev/sdc

WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

adding device /dev/sdc id 2
fs created label (null) on /dev/sda4
        nodesize 4096 leafsize 4096 sectorsize 4096 size 3.97TB
Btrfs Btrfs v0.19
backup6:~/btrfs-progs# ./btrfs fi show /dev/sdc
Label: none  uuid: 806b237e-53ed-409e-a7c1-02f101798384
        Total devices 2 FS bytes used 28.00KB
        devid    2 size 1.98TB used 2.01GB path /dev/sdc
        devid    1 size 1.98TB used 2.03GB path /dev/sda4

Btrfs Btrfs v0.19


# ./mkfs.btrfs /dev/sdc /dev/sda4

WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

adding device /dev/sda4 id 2
fs created label (null) on /dev/sdc
        nodesize 4096 leafsize 4096 sectorsize 4096 size 4.71TB
Btrfs Btrfs v0.19
backup6:~/btrfs-progs# ./btrfs fi show /dev/sdc
Label: none  uuid: 8f99c072-521b-4827-a2be-41de6ab11b4f
        Total devices 2 FS bytes used 28.00KB
        devid    1 size 2.73TB used 2.03GB path /dev/sdc
        devid    2 size 1.98TB used 2.01GB path /dev/sda4

Btrfs Btrfs v0.19


Thanks.

-- 
Cyril B.

Re: mkfs devices ordering relevant with devices of different sizes?

[David Sterba]

On Wed, Jul 25, 2012 at 03:26:20PM +0200, Cyril B.  wrote:
> When creating a filesystem with devices of different sizes, the resulting 
> filesystem total size depends on the device order specified to mkfs. When 
> the smaller device is specified first, the second (larger) device is seen as 
> the same size as the first. This doesn't occur when the order is reversed.
> 
> It's confusing. Is this expected? I'm using the latest btrfs-progs and Linux 
> 3.5.

Confusing it is, caused by this commit

Author:     Josef Bacik <josef@redhat.com>
AuthorDate: Wed Mar 28 14:20:52 2012 -0400
Commit:     Chris Mason <chris.mason@fusionio.com>
CommitDate: Tue Jul 3 16:27:46 2012 -0400

    btrfs-progs: enforce block count on all devices in mkfs

    I had a test that creates a 7gig raid1 device but it was ending up wonky
    because the second device that gets added is the full size of the disk
    instead of the limited size.  So enforce the limited size on all disks
    passed in at mkfs time, otherwise our threshold calculations end up wonky
    when doing chunk allocations.  Thanks,
---


david

Re: mkfs devices ordering relevant with devices of different sizes?

[Josef Bacik]

On Thu, Jul 26, 2012 at 03:09:59PM -0600, David Sterba wrote:
> On Wed, Jul 25, 2012 at 03:26:20PM +0200, Cyril B.  wrote:
> > When creating a filesystem with devices of different sizes, the resulting 
> > filesystem total size depends on the device order specified to mkfs. When 
> > the smaller device is specified first, the second (larger) device is seen as 
> > the same size as the first. This doesn't occur when the order is reversed.
> > 
> > It's confusing. Is this expected? I'm using the latest btrfs-progs and Linux 
> > 3.5.
> 
> Confusing it is, caused by this commit
> 
> Author:     Josef Bacik <josef@redhat.com>
> AuthorDate: Wed Mar 28 14:20:52 2012 -0400
> Commit:     Chris Mason <chris.mason@fusionio.com>
> CommitDate: Tue Jul 3 16:27:46 2012 -0400
> 
>     btrfs-progs: enforce block count on all devices in mkfs
> 
>     I had a test that creates a 7gig raid1 device but it was ending up wonky
>     because the second device that gets added is the full size of the disk
>     instead of the limited size.  So enforce the limited size on all disks
>     passed in at mkfs time, otherwise our threshold calculations end up wonky
>     when doing chunk allocations.  Thanks,

Ooops, that's definitely not what I intended, I will fix that up right away,
sorry about that.  Thanks,

Josef