Wierd partition behaviour with BTRFS

Chris Murphy lists at colorremedies.com
Fri Mar 14 00:46:02 UTC 2014


On Mar 13, 2014, at 6:23 PM, Patrick O'Callaghan <pocallaghan at gmail.com> wrote:

> On Thu, 2014-03-13 at 14:27 -0600, Chris Murphy wrote:
>> 
>> 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.

It's the default behavior for multiple device Btrfs volumes.


>>> 
>>>> 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.

That's what I'm seeing with 3.13.6 and 3.14rc6 as well. With ext4, e2label changes /dev/disk/by-label immediately no reboot or even remount needed.

> 
>> 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.

For what it's worth, if you experience Btrfs problems, using a newer kernel is often one of the first steps for solving it. It comes even before running btrfs check (a.k.a. btrfsck).


Chris Murphy



More information about the users mailing list