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