Wierd partition behaviour with BTRFS

[Patrick O'Callaghan]

On Thu, 2014-03-13 at 14:27 -0600, Chris Murphy wrote:
> >> btrfs fi df /home     #this is short for btrfs filesystem df /home
> > 
> > $ sudo btrfs fi df /home
> > Data, single: total=78.01GiB, used=73.44GiB
> ^^^^^^^^^
> 
> So this means the data profile is single, which means it's allocating
> in 1GB chunks, alternating devices once they have the same free space
> remaining.

OK

> 
> > System, RAID1: total=8.00MiB, used=16.00KiB
> > Metadata, RAID1: total=1.00GiB, used=295.20Mi
> ^^^^^^^^^^^
> 
> And metadata is raid1 so it's mirrored on both devices.

Absolutely no idea how that happened. I definitely did not
(intentionally at least) ask for RAID1.

> > I'm wondering where the bulk of the 1TB HDD has gone.
> 
> Your btrfs fi show will reveal the breakdown:
> 
> > 
> > $ sudo btrfs fi show
> > Label: xtra  uuid: 22fecad3-619d-4a9b-aace-35a2e4e04c49
> >        Total devices 2 FS bytes used 73.72GiB
> >        devid    1 size 4.19GiB used 1.03GiB path /dev/sda2
> >        devid    2 size 927.32GiB used 79.01GiB path /dev/sdb1
> 
> So there is a 1GB allocation on the SSD, and 79GB allocation on the
> HDD, which is consistent with the single profile filling up the device
> with the most free space first. Once free space is equal, it will
> alternate allocations between the two drives.

Right.

> 
> > 
> > 
> >> And does the first line Label: match the new label or the old?
> > 
> > xtra is the new label. /dev/disk/by-label still shows the old label
> and
> > not the new one.
> 
> Does the old one persist after a reboot?

After reboot I'm seeing the new label instead of the old one, so that's
something.

> There's a huge pile of btrfs patches in 3.14 so it'd be interesting if
> you get different results with 3.14.0-0.rc6.git0.1.fc21.x86_64
> available in koji (which is NOT a debug kernel, newer ones are unless
> otherwise specified in the changelog section; typically the first
> build on Monday after the release of a new rc version on kernel.org is
> git0 and is not a debug kernel so you can use it on F20; the debug
> kernels are much much slower).

Maybe so, but I'm not sure I want to get into kernel testing right now.

poc