"Btrfs: device_list_add() should not update list when mounted" breaks subvol mount

"Btrfs: device_list_add() should not update list when mounted" breaks subvol mount

[Johannes Hirte]

commit b96de000bc8bc9688b3a2abea4332bd57648a49f breaks subvolume mount
on one of my systems. I've bisected a mount problem to this commit.
Situation is:

- one hdd with btrfs
- default subvolume (rootfs) is different from subovlid=0
- at boot, several subvols are mounted at /home/$DIR

after commit b96de000bc8bc9688b3a2abea4332bd57648a49f this is not
possible anymore. Trying to mount results in (example):

mount: /dev/sda1 is already mounted or /home/video busy

The output of btrfs show is curious too:

btrfs fi show
Label: none  uuid: 43438ef5-adac-46a9-823e-14951ee6866a
        Total devices 1 FS bytes used 150.05GiB
        *** Some devices missing

Btrfs v3.16

As this is a laptop with only one drive bay, this was never a multi
device setup. I've two more systems with kernel version >3.17-rc3
running and no problem like this.

regards,
  Johannes

Re: "Btrfs: device_list_add() should not update list when mounted" breaks subvol mount

[Anand Jain]

  that's shocking. Let me take a look.

Thanks for reporting.
Anand


On 09/11/14 06:22 AM, Johannes Hirte wrote:
> commit b96de000bc8bc9688b3a2abea4332bd57648a49f breaks subvolume mount
> on one of my systems. I've bisected a mount problem to this commit.
> Situation is:
>
> - one hdd with btrfs
> - default subvolume (rootfs) is different from subovlid=0
> - at boot, several subvols are mounted at /home/$DIR
>
> after commit b96de000bc8bc9688b3a2abea4332bd57648a49f this is not
> possible anymore. Trying to mount results in (example):
>
> mount: /dev/sda1 is already mounted or /home/video busy
>
> The output of btrfs show is curious too:
>
> btrfs fi show
> Label: none  uuid: 43438ef5-adac-46a9-823e-14951ee6866a
>          Total devices 1 FS bytes used 150.05GiB
>          *** Some devices missing
>
> Btrfs v3.16
>
> As this is a laptop with only one drive bay, this was never a multi
> device setup. I've two more systems with kernel version >3.17-rc3
> running and no problem like this.
>
> regards,
>    Johannes
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: "Btrfs: device_list_add() should not update list when mounted" breaks subvol mount

[Anand Jain]

Hi Johannes,

> I've two more systems with kernel version >3.17-rc3
> running and no problem like this.

  Does this 3.17-rc3 also has the same type of subvol config
  and it mount operation/sequence as you mentioned ?

 > - one hdd with btrfs
 > - default subvolume (rootfs) is different from subovlid=0
 > - at boot, several subvols are mounted at /home/$DIR

  I ran a few tests, on our mainline
  ----
  mount -o subvol=sv1 /dev/sdh1 /btrfs
  mount /dev/sdh1 /btrfs
   mount: /dev/sdh1 already mounted or /btrfs busy [*]
  mount /dev/sdh1 /btrfs1
  echo $?
  0
  -----

  [*] hope this isn't the problem you are mentioning.

Thanks, Anand

Re: "Btrfs: device_list_add() should not update list when mounted" breaks subvol mount

[xavier.gnata]

Hi,

On standard ubuntu 14.04 a with an encrypted (cryptsetup) /home as brtfs 
subvolume we have the following results:
3.17-rc2 : Ok.
3.17-rc3 and 3.17-rc4 :  /home fails to mount on boot. If one try mount 
-a then the system tells that the partition is already mounted according 
to matab.


On a 3.17-rc4, btrfs fi sh returns nothing special:
"
Label: none  uuid: f4f554bb-57d9-4647-ab14-ea978c9e7e9f
         Total devices 1 FS bytes used 131.41GiB
         devid    1 size 173.31GiB used 134.03GiB path /dev/sda5

Btrfs v3.12
"

I'm not sure if it has something to do with cryptsetup...


Xavier

> Hi Johannes,
>
>> I've two more systems with kernel version >3.17-rc3
>> running and no problem like this.
>
>  Does this 3.17-rc3 also has the same type of subvol config
>  and it mount operation/sequence as you mentioned ?
>
> > - one hdd with btrfs
> > - default subvolume (rootfs) is different from subovlid=0
> > - at boot, several subvols are mounted at /home/$DIR
>
>  I ran a few tests, on our mainline
>  ----
>  mount -o subvol=sv1 /dev/sdh1 /btrfs
>  mount /dev/sdh1 /btrfs
>   mount: /dev/sdh1 already mounted or /btrfs busy [*]
>  mount /dev/sdh1 /btrfs1
>  echo $?
>  0
>  -----
>
>  [*] hope this isn't the problem you are mentioning.
>
> Thanks, Anand
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: "Btrfs: device_list_add() should not update list when mounted" breaks subvol mount

[Anand Jain]

Hi Xavier,

  Thanks for the report.

  I got this reproduced: its a very corner case, it depends on the
  device path given in the subsequent subvol mounts, the fix appear
  to be outside of this patch at this moment and I am digging to know
  if we need to normalize the device path before using it in the btrfs
  kernel, just like btrfs-progs did recently.


  reproducer:
  ls -l /root/dev/sde-link
    /root/dev/sde-link -> /dev/sde

  mount -o device=/root/dev/sde-link /dev/sdd /btrfs1
  btrfs fi show
  Label: none  uuid: 943bf422-998c-4640-9d7f-d49f17b782ce
	Total devices 2 FS bytes used 272.00KiB
	devid    1 size 1.52GiB used 339.50MiB path /dev/sdd
	devid    2 size 1.52GiB used 319.50MiB path /root/dev/sde-link

  mount -o subvol=sv1,device=/dev/sde /dev/sdd /btrfs  <-shouldn't fail.
   mount: /dev/sdd already mounted or /btrfs busy
   mount: according to mtab, /dev/sdd is mounted on /btrfs1

  mount -o device=/root/dev/sde-link /dev/sdd /btrfs
   echo $?
   0


Xavier, Johannes,

     The quickest workaround for you will be to try to match
  the device path as in the btrfs fi show -m </mnt> output to
  your probably fstab/mnttab entry.


Anand

On 09/13/2014 04:43 AM, xavier.gnata@gmail.com wrote:
> Hi,
>
> On standard ubuntu 14.04 a with an encrypted (cryptsetup) /home as brtfs
> subvolume we have the following results:
> 3.17-rc2 : Ok.
> 3.17-rc3 and 3.17-rc4 :  /home fails to mount on boot. If one try mount
> -a then the system tells that the partition is already mounted according
> to matab.


>
> On a 3.17-rc4, btrfs fi sh returns nothing special:
> "
> Label: none  uuid: f4f554bb-57d9-4647-ab14-ea978c9e7e9f
>          Total devices 1 FS bytes used 131.41GiB
>          devid    1 size 173.31GiB used 134.03GiB path /dev/sda5
>
> Btrfs v3.12
> "
>
> I'm not sure if it has something to do with cryptsetup...
>
>
> Xavier
>
>> Hi Johannes,
>>
>>> I've two more systems with kernel version >3.17-rc3
>>> running and no problem like this.
>>
>>  Does this 3.17-rc3 also has the same type of subvol config
>>  and it mount operation/sequence as you mentioned ?
>>
>> > - one hdd with btrfs
>> > - default subvolume (rootfs) is different from subovlid=0
>> > - at boot, several subvols are mounted at /home/$DIR
>>
>>  I ran a few tests, on our mainline
>>  ----
>>  mount -o subvol=sv1 /dev/sdh1 /btrfs
>>  mount /dev/sdh1 /btrfs
>>   mount: /dev/sdh1 already mounted or /btrfs busy [*]
>>  mount /dev/sdh1 /btrfs1
>>  echo $?
>>  0
>>  -----
>>
>>  [*] hope this isn't the problem you are mentioning.
>>
>> Thanks, Anand

Re: "Btrfs: device_list_add() should not update list when mounted" breaks subvol mount

[Johannes Hirte]

On Sat, 13 Sep 2014 13:36:37 +0800
Anand Jain <Anand.Jain@oracle.com> wrote:

> Xavier, Johannes,
> 
>      The quickest workaround for you will be to try to match
>   the device path as in the btrfs fi show -m </mnt> output to
>   your probably fstab/mnttab entry.

Doesn't work here. I don't even get a path with the affected kernels.
I'll get:

Label: none  uuid: 02edbd6b-f044-4800-b21e-ca8982c2c2e5
        Total devices 1 FS bytes used 270.10GiB
        *** Some devices missing

Btrfs v3.16

with a working kernel:

Label: none  uuid: 02edbd6b-f044-4800-b21e-ca8982c2c2e5
        Total devices 1 FS bytes used 270.10GiB
        devid    1 size 293.89GiB used 289.06GiB path /dev/sda1

Btrfs v3.16

Filesystem layout is:

subvolid 0 contains only the different subvolumes

ID 257 gen 414674 top level 5 path rootfs
ID 269 gen 414615 top level 5 path home-USER1
ID 317 gen 411498 top level 5 path home-USER2
ID 363 gen 410939 top level 5 path home-USER3
ID 382 gen 315844 top level 5 path home-USER4
ID 933 gen 410514 top level 5 path home-USER5
ID 995 gen 315756 top level 5 path homefs-USER6

subvol rootfs (ID 257) is set to the default subvolume, mounted at
start. Grub commandline is like following:

root=/dev/sda1 ro rootflags=subvol=rootfs,inode_cache,autodefrag

It doesn't matter, if the subvol parameter is set. I've tried with,
without and with subvolid=0 parameter. Everytime the same result.


And now I was able to reproduce on a second machine. The main
difference between the affected and the unaffected systems is
initramfs. On the affected systems, I don't use one. On the working
systems, the rootfs is mounted via initramfs before. I'll test, if an
initramfs will solve the issue. Seems likely, cause if I put the disk
of an affected system into a working system and mount it there,
everything works.


regards,
  Johannes

Re: "Btrfs: device_list_add() should not update list when mounted" breaks subvol mount

[Johannes Hirte]

On Sat, 13 Sep 2014 19:55:25 +0200
Johannes Hirte <johannes.hirte@datenkhaos.de> wrote:

> On Sat, 13 Sep 2014 13:36:37 +0800
> Anand Jain <Anand.Jain@oracle.com> wrote:
> 
> > Xavier, Johannes,
> > 
> >      The quickest workaround for you will be to try to match
> >   the device path as in the btrfs fi show -m </mnt> output to
> >   your probably fstab/mnttab entry.
> 
> Doesn't work here. I don't even get a path with the affected kernels.
> I'll get:
> 
> Label: none  uuid: 02edbd6b-f044-4800-b21e-ca8982c2c2e5
>         Total devices 1 FS bytes used 270.10GiB
>         *** Some devices missing
> 
> Btrfs v3.16
> 
> with a working kernel:
> 
> Label: none  uuid: 02edbd6b-f044-4800-b21e-ca8982c2c2e5
>         Total devices 1 FS bytes used 270.10GiB
>         devid    1 size 293.89GiB used 289.06GiB path /dev/sda1
> 
> Btrfs v3.16
> 
> Filesystem layout is:
> 
> subvolid 0 contains only the different subvolumes
> 
> ID 257 gen 414674 top level 5 path rootfs
> ID 269 gen 414615 top level 5 path home-USER1
> ID 317 gen 411498 top level 5 path home-USER2
> ID 363 gen 410939 top level 5 path home-USER3
> ID 382 gen 315844 top level 5 path home-USER4
> ID 933 gen 410514 top level 5 path home-USER5
> ID 995 gen 315756 top level 5 path homefs-USER6
> 
> subvol rootfs (ID 257) is set to the default subvolume, mounted at
> start. Grub commandline is like following:
> 
> root=/dev/sda1 ro rootflags=subvol=rootfs,inode_cache,autodefrag
> 
> It doesn't matter, if the subvol parameter is set. I've tried with,
> without and with subvolid=0 parameter. Everytime the same result.
> 
> 
> And now I was able to reproduce on a second machine. The main
> difference between the affected and the unaffected systems is
> initramfs. On the affected systems, I don't use one. On the working
> systems, the rootfs is mounted via initramfs before. I'll test, if an
> initramfs will solve the issue. Seems likely, cause if I put the disk
> of an affected system into a working system and mount it there,
> everything works.

Of course, with the initramfs it works. Content of the init-script:

#!/bin/sh

mount -t devtmpfs devtmpfs /dev
mount -t proc proc /proc
mount -t sysfs sysfs /sys
mount -t tmpfs tmpfs /run
sleep 3  # wait for kernel msgs to quiet

echo "loading initrd"

btrfs dev scan
sleep 5

mount -o ro,subvol=rootfs,inode_cache,autodefrag /dev/sda1 /newroot

if [[ -x /newroot/sbin/init ]]; then
        umount /sys /proc
        exec switch_root /newroot /sbin/init
fi

#rescue shell
exec sh

Re: "Btrfs: device_list_add() should not update list when mounted" breaks subvol mount

[Duncan]

Johannes Hirte posted on Sat, 13 Sep 2014 23:23:20 +0200 as excerpted:

> On Sat, 13 Sep 2014 19:55:25 +0200 Johannes Hirte
> <johannes.hirte@datenkhaos.de> wrote:
> 
>> On Sat, 13 Sep 2014 13:36:37 +0800 Anand Jain <Anand.Jain@oracle.com>
>> wrote:
>> 
>>> The quickest workaround for you will be to try to match
>>> the device path as in the btrfs fi show -m </mnt> output to your
>>> probably fstab/mnttab entry.
>> 
>> Doesn't work here. I don't even get a path with the affected kernels.
>> I'll get:
>> 
>> Label: none  uuid: 02edbd6b-f044-4800-b21e-ca8982c2c2e5
>>         Total devices 1 FS bytes used 270.10GiB
>>         *** Some devices missing
>> 
>> Btrfs v3.16
>> 
>> with a working kernel:
>> 
>> Label: none  uuid: 02edbd6b-f044-4800-b21e-ca8982c2c2e5
>>         Total devices 1 FS bytes used 270.10GiB
>>         devid  1 size 293.89GiB used 289.06GiB path /dev/sda1
>> 
>> Btrfs v3.16

>> And now I was able to reproduce on a second machine. The main
>> difference between the affected and the unaffected systems is
>> initramfs. On the affected systems, I don't use one. On the working
>> systems, the rootfs is mounted via initramfs before. I'll test, if an
>> initramfs will solve the issue. Seems likely, cause if I put the disk
>> of an affected system into a working system and mount it there,
>> everything works.
> 
> Of course, with the initramfs it works.

I see a btrfs device scan in the initramfs script.  What happens if you 
simply run btrfs device scan manually, before doing btrfs filesystem show?

I'm guessing that'll fix it.

Explanation assuming it does: Without the scan and without an initr*, 
you're pointing the kernel directly at the single-device btrfs using the 
root= kernel commandline option and that works, but the kernel still 
doesn't really know what device it's dealing with until after a scan to 
tell it.

If that doesn't fix it, I'm guessing the same explanation, but for some 
reason the scan has to be run before the filesystem is mounted.  Thus 
running it from the initr* works, since it's before the real-root gets 
mounted, but running it directly from the mounted root after it's mounted 
using root= doesn't work, because it's already mounted by the time the 
scan is run.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: "Btrfs: device_list_add() should not update list when mounted" breaks subvol mount

[Johannes Hirte]

On Sun, 14 Sep 2014 00:45:49 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> Johannes Hirte posted on Sat, 13 Sep 2014 23:23:20 +0200 as excerpted:
> 
> > On Sat, 13 Sep 2014 19:55:25 +0200 Johannes Hirte
> > <johannes.hirte@datenkhaos.de> wrote:
> > 
> >> On Sat, 13 Sep 2014 13:36:37 +0800 Anand Jain
> >> <Anand.Jain@oracle.com> wrote:
> >> 
> >>> The quickest workaround for you will be to try to match
> >>> the device path as in the btrfs fi show -m </mnt> output to your
> >>> probably fstab/mnttab entry.
> >> 
> >> Doesn't work here. I don't even get a path with the affected
> >> kernels. I'll get:
> >> 
> >> Label: none  uuid: 02edbd6b-f044-4800-b21e-ca8982c2c2e5
> >>         Total devices 1 FS bytes used 270.10GiB
> >>         *** Some devices missing
> >> 
> >> Btrfs v3.16
> >> 
> >> with a working kernel:
> >> 
> >> Label: none  uuid: 02edbd6b-f044-4800-b21e-ca8982c2c2e5
> >>         Total devices 1 FS bytes used 270.10GiB
> >>         devid  1 size 293.89GiB used 289.06GiB path /dev/sda1
> >> 
> >> Btrfs v3.16
> 
> >> And now I was able to reproduce on a second machine. The main
> >> difference between the affected and the unaffected systems is
> >> initramfs. On the affected systems, I don't use one. On the working
> >> systems, the rootfs is mounted via initramfs before. I'll test, if
> >> an initramfs will solve the issue. Seems likely, cause if I put
> >> the disk of an affected system into a working system and mount it
> >> there, everything works.
> > 
> > Of course, with the initramfs it works.
> 
> I see a btrfs device scan in the initramfs script.  What happens if
> you simply run btrfs device scan manually, before doing btrfs
> filesystem show?
> 
> I'm guessing that'll fix it.

Not tested, but I doubt it will fix it. In this initramfs it is a
leftover from a time, when the system was multi-device. On two other
systems, initramfs works without the scan. Additionally I can put the
affected HDD from the laptop and put it into/on another system, that is
affected without initramfs. I can mount it there without any scan
before. But I'm not 100% sure if udev takes responsibility for scanning
here.

regards,
  Johannes

Re: "Btrfs: device_list_add() should not update list when mounted" breaks subvol mount

[Anand Jain]

Hi Johannes,

  Can I have you this tested.. ? Thanks.


-------
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index e9676a4..1224b61 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -533,7 +533,7 @@ static noinline int device_list_add(const char *path,
                  * the btrfs dev scan cli, after FS has been mounted.
                  */
                 if (fs_devices->opened) {
-                       return -EBUSY;
+                       goto out;
                 } else {
                         /*
                          * That is if the FS is _not_ mounted and if you
@@ -566,6 +566,7 @@ static noinline int device_list_add(const char *path,
         if (!fs_devices->opened)
                 device->generation = found_transid;

+out:
         *fs_devices_ret = fs_devices;

         return ret;
-------

Anand



On 09/14/2014 05:23 AM, Johannes Hirte wrote:
> On Sat, 13 Sep 2014 19:55:25 +0200
> Johannes Hirte <johannes.hirte@datenkhaos.de> wrote:
>
>> On Sat, 13 Sep 2014 13:36:37 +0800
>> Anand Jain <Anand.Jain@oracle.com> wrote:
>>
>>> Xavier, Johannes,
>>>
>>>       The quickest workaround for you will be to try to match
>>>    the device path as in the btrfs fi show -m </mnt> output to
>>>    your probably fstab/mnttab entry.
>>
>> Doesn't work here. I don't even get a path with the affected kernels.
>> I'll get:
>>
>> Label: none  uuid: 02edbd6b-f044-4800-b21e-ca8982c2c2e5
>>          Total devices 1 FS bytes used 270.10GiB
>>          *** Some devices missing
>>
>> Btrfs v3.16
>>
>> with a working kernel:
>>
>> Label: none  uuid: 02edbd6b-f044-4800-b21e-ca8982c2c2e5
>>          Total devices 1 FS bytes used 270.10GiB
>>          devid    1 size 293.89GiB used 289.06GiB path /dev/sda1
>>
>> Btrfs v3.16
>>
>> Filesystem layout is:
>>
>> subvolid 0 contains only the different subvolumes
>>
>> ID 257 gen 414674 top level 5 path rootfs
>> ID 269 gen 414615 top level 5 path home-USER1
>> ID 317 gen 411498 top level 5 path home-USER2
>> ID 363 gen 410939 top level 5 path home-USER3
>> ID 382 gen 315844 top level 5 path home-USER4
>> ID 933 gen 410514 top level 5 path home-USER5
>> ID 995 gen 315756 top level 5 path homefs-USER6
>>
>> subvol rootfs (ID 257) is set to the default subvolume, mounted at
>> start. Grub commandline is like following:
>>
>> root=/dev/sda1 ro rootflags=subvol=rootfs,inode_cache,autodefrag
>>
>> It doesn't matter, if the subvol parameter is set. I've tried with,
>> without and with subvolid=0 parameter. Everytime the same result.
>>
>>
>> And now I was able to reproduce on a second machine. The main
>> difference between the affected and the unaffected systems is
>> initramfs. On the affected systems, I don't use one. On the working
>> systems, the rootfs is mounted via initramfs before. I'll test, if an
>> initramfs will solve the issue. Seems likely, cause if I put the disk
>> of an affected system into a working system and mount it there,
>> everything works.
>
> Of course, with the initramfs it works. Content of the init-script:
>
> #!/bin/sh
>
> mount -t devtmpfs devtmpfs /dev
> mount -t proc proc /proc
> mount -t sysfs sysfs /sys
> mount -t tmpfs tmpfs /run
> sleep 3  # wait for kernel msgs to quiet
>
> echo "loading initrd"
>
> btrfs dev scan
> sleep 5
>
> mount -o ro,subvol=rootfs,inode_cache,autodefrag /dev/sda1 /newroot
>
> if [[ -x /newroot/sbin/init ]]; then
>          umount /sys /proc
>          exec switch_root /newroot /sbin/init
> fi
>
> #rescue shell
> exec sh
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: "Btrfs: device_list_add() should not update list when mounted" breaks subvol mount

[Johannes Hirte]

On Mon, 15 Sep 2014 20:32:58 +0800
Anand Jain <Anand.Jain@oracle.com> wrote:

> 
> 
> Hi Johannes,
> 
>   Can I have you this tested.. ? Thanks.
> 
> 
> -------
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index e9676a4..1224b61 100644
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -533,7 +533,7 @@ static noinline int device_list_add(const char
> *path,
>                   * the btrfs dev scan cli, after FS has been mounted.
>                   */
>                  if (fs_devices->opened) {
> -                       return -EBUSY;
> +                       goto out;
>                  } else {
>                          /*
>                           * That is if the FS is _not_ mounted and if
> you @@ -566,6 +566,7 @@ static noinline int device_list_add(const
> char *path, if (!fs_devices->opened)
>                  device->generation = found_transid;
> 
> +out:
>          *fs_devices_ret = fs_devices;
> 
>          return ret;
> -------

With this change, it works again without initramfs.

regards,
  Johannes

Re: "Btrfs: device_list_add() should not update list when mounted" breaks subvol mount

[Anand Jain]

On 16/09/2014 01:14, Johannes Hirte wrote:
> On Mon, 15 Sep 2014 20:32:58 +0800
> Anand Jain <Anand.Jain@oracle.com> wrote:
>
>>
>>
>> Hi Johannes,
>>
>>    Can I have you this tested.. ? Thanks.
>>
>>
>> -------
>> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
>> index e9676a4..1224b61 100644
>> --- a/fs/btrfs/volumes.c
>> +++ b/fs/btrfs/volumes.c
>> @@ -533,7 +533,7 @@ static noinline int device_list_add(const char
>> *path,
>>                    * the btrfs dev scan cli, after FS has been mounted.
>>                    */
>>                   if (fs_devices->opened) {
>> -                       return -EBUSY;
>> +                       goto out;
>>                   } else {
>>                           /*
>>                            * That is if the FS is _not_ mounted and if
>> you @@ -566,6 +566,7 @@ static noinline int device_list_add(const
>> char *path, if (!fs_devices->opened)
>>                   device->generation = found_transid;
>>
>> +out:
>>           *fs_devices_ret = fs_devices;
>>
>>           return ret;
>> -------
>
> With this change, it works again without initramfs.

  Thanks. I am bit confused, is there any configuration that is
  still not working, even with the above changes.

Anand


> regards,
>    Johannes
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: "Btrfs: device_list_add() should not update list when mounted" breaks subvol mount

[Johannes Hirte]

On Tue, 16 Sep 2014 01:39:49 +0800
Anand Jain <Anand.Jain@oracle.com> wrote:

> 
> 
> On 16/09/2014 01:14, Johannes Hirte wrote:
> > On Mon, 15 Sep 2014 20:32:58 +0800
> > Anand Jain <Anand.Jain@oracle.com> wrote:
> >
> >>
> >>
> >> Hi Johannes,
> >>
> >>    Can I have you this tested.. ? Thanks.
> >>
> >>
> >> -------
> >> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> >> index e9676a4..1224b61 100644
> >> --- a/fs/btrfs/volumes.c
> >> +++ b/fs/btrfs/volumes.c
> >> @@ -533,7 +533,7 @@ static noinline int device_list_add(const char
> >> *path,
> >>                    * the btrfs dev scan cli, after FS has been
> >> mounted. */
> >>                   if (fs_devices->opened) {
> >> -                       return -EBUSY;
> >> +                       goto out;
> >>                   } else {
> >>                           /*
> >>                            * That is if the FS is _not_ mounted
> >> and if you @@ -566,6 +566,7 @@ static noinline int
> >> device_list_add(const char *path, if (!fs_devices->opened)
> >>                   device->generation = found_transid;
> >>
> >> +out:
> >>           *fs_devices_ret = fs_devices;
> >>
> >>           return ret;
> >> -------
> >
> > With this change, it works again without initramfs.
> 
>   Thanks. I am bit confused, is there any configuration that is
>   still not working, even with the above changes.
> 
> Anand

At moment, I'm not aware of any. But I will test the remaining systems
I have.

regards,
  Johannes

Re: "Btrfs: device_list_add() should not update list when mounted" breaks subvol mount

[Anand Jain]

Johannes, Xavier,

  Can you pls send the output for ..

    cat /etc/fstab  | egrep btrfs
    cat /proc/self/mounts | egrep btrfs
    mount | egrep btrfs

Thanks, Anand


On 16/09/2014 06:17, Johannes Hirte wrote:
> On Tue, 16 Sep 2014 01:39:49 +0800
> Anand Jain <Anand.Jain@oracle.com> wrote:
>
>>
>>
>> On 16/09/2014 01:14, Johannes Hirte wrote:
>>> On Mon, 15 Sep 2014 20:32:58 +0800
>>> Anand Jain <Anand.Jain@oracle.com> wrote:
>>>
>>>>
>>>>
>>>> Hi Johannes,
>>>>
>>>>     Can I have you this tested.. ? Thanks.
>>>>
>>>>
>>>> -------
>>>> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
>>>> index e9676a4..1224b61 100644
>>>> --- a/fs/btrfs/volumes.c
>>>> +++ b/fs/btrfs/volumes.c
>>>> @@ -533,7 +533,7 @@ static noinline int device_list_add(const char
>>>> *path,
>>>>                     * the btrfs dev scan cli, after FS has been
>>>> mounted. */
>>>>                    if (fs_devices->opened) {
>>>> -                       return -EBUSY;
>>>> +                       goto out;
>>>>                    } else {
>>>>                            /*
>>>>                             * That is if the FS is _not_ mounted
>>>> and if you @@ -566,6 +566,7 @@ static noinline int
>>>> device_list_add(const char *path, if (!fs_devices->opened)
>>>>                    device->generation = found_transid;
>>>>
>>>> +out:
>>>>            *fs_devices_ret = fs_devices;
>>>>
>>>>            return ret;
>>>> -------
>>>
>>> With this change, it works again without initramfs.
>>
>>    Thanks. I am bit confused, is there any configuration that is
>>    still not working, even with the above changes.
>>
>> Anand
>
> At moment, I'm not aware of any. But I will test the remaining systems
> I have.
>
> regards,
>    Johannes
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: "Btrfs: device_list_add() should not update list when mounted" breaks subvol mount

[Anand Jain]

>> And now I was able to reproduce on a second machine. The main
>> difference between the affected and the unaffected systems is
>> initramfs. On the affected systems, I don't use one.

  In this test of with or without initramfs script. I guess the kernel
  remain same at 3.17-rc3 and above

>> On the working
>> systems, the rootfs is mounted via initramfs before. I'll test, if an
>> initramfs will solve the issue. Seems likely, cause if I put the disk
>> of an affected system into a working system and mount it there,
>> everything works.
>
> Of course, with the initramfs it works. Content of the init-script:
>
> #!/bin/sh
>
> mount -t devtmpfs devtmpfs /dev
> mount -t proc proc /proc
> mount -t sysfs sysfs /sys
> mount -t tmpfs tmpfs /run
> sleep 3  # wait for kernel msgs to quiet
>
> echo "loading initrd"
>
> btrfs dev scan
> sleep 5
>
> mount -o ro,subvol=rootfs,inode_cache,autodefrag /dev/sda1 /newroot

  this will work since the device path that we provide here
  is already the device path which probably will be the final
  device path after bootup.

Thanks

> if [[ -x /newroot/sbin/init ]]; then
>          umount /sys /proc
>          exec switch_root /newroot /sbin/init
> fi
>
> #rescue shell
> exec sh

Re: "Btrfs: device_list_add() should not update list when mounted" breaks subvol mount

[xavier.gnata]

The way an encrypted home is mounted is based on links as described here:
https://help.ubuntu.com/community/EncryptedPrivateDirectory
It used to be ok before 3.17-rc3 and df -h shows:
/dev/sda5             363G  128G  217G  38% /
/home/gnata/.Private  363G  128G  217G  38% /home/gnata

It is suppose to work with a kernel >3.17-rc3 when "home" btrfs is a 
subvolume?
Does it make sense to test "[PATCH] btrfs-progs: canonicalize pathnames 
for device commands" or it is premature?

Xavier
>
> Hi Xavier,
>
>  Thanks for the report.
>
>  I got this reproduced: its a very corner case, it depends on the
>  device path given in the subsequent subvol mounts, the fix appear
>  to be outside of this patch at this moment and I am digging to know
>  if we need to normalize the device path before using it in the btrfs
>  kernel, just like btrfs-progs did recently.
>
>
>  reproducer:
>  ls -l /root/dev/sde-link
>    /root/dev/sde-link -> /dev/sde
>
>  mount -o device=/root/dev/sde-link /dev/sdd /btrfs1
>  btrfs fi show
>  Label: none  uuid: 943bf422-998c-4640-9d7f-d49f17b782ce
>     Total devices 2 FS bytes used 272.00KiB
>     devid    1 size 1.52GiB used 339.50MiB path /dev/sdd
>     devid    2 size 1.52GiB used 319.50MiB path /root/dev/sde-link
>
>  mount -o subvol=sv1,device=/dev/sde /dev/sdd /btrfs <-shouldn't fail.
>   mount: /dev/sdd already mounted or /btrfs busy
>   mount: according to mtab, /dev/sdd is mounted on /btrfs1
>
>  mount -o device=/root/dev/sde-link /dev/sdd /btrfs
>   echo $?
>   0
>
>
> Xavier, Johannes,
>
>     The quickest workaround for you will be to try to match
>  the device path as in the btrfs fi show -m </mnt> output to
>  your probably fstab/mnttab entry.
>
>
> Anand
>
> On 09/13/2014 04:43 AM, xavier.gnata@gmail.com wrote:
>> Hi,
>>
>> On standard ubuntu 14.04 a with an encrypted (cryptsetup) /home as brtfs
>> subvolume we have the following results:
>> 3.17-rc2 : Ok.
>> 3.17-rc3 and 3.17-rc4 :  /home fails to mount on boot. If one try mount
>> -a then the system tells that the partition is already mounted according
>> to matab.
>
>
>>
>> On a 3.17-rc4, btrfs fi sh returns nothing special:
>> "
>> Label: none  uuid: f4f554bb-57d9-4647-ab14-ea978c9e7e9f
>>          Total devices 1 FS bytes used 131.41GiB
>>          devid    1 size 173.31GiB used 134.03GiB path /dev/sda5
>>
>> Btrfs v3.12
>> "
>>
>> I'm not sure if it has something to do with cryptsetup...
>>
>>
>> Xavier
>>
>>> Hi Johannes,
>>>
>>>> I've two more systems with kernel version >3.17-rc3
>>>> running and no problem like this.
>>>
>>>  Does this 3.17-rc3 also has the same type of subvol config
>>>  and it mount operation/sequence as you mentioned ?
>>>
>>> > - one hdd with btrfs
>>> > - default subvolume (rootfs) is different from subovlid=0
>>> > - at boot, several subvols are mounted at /home/$DIR
>>>
>>>  I ran a few tests, on our mainline
>>>  ----
>>>  mount -o subvol=sv1 /dev/sdh1 /btrfs
>>>  mount /dev/sdh1 /btrfs
>>>   mount: /dev/sdh1 already mounted or /btrfs busy [*]
>>>  mount /dev/sdh1 /btrfs1
>>>  echo $?
>>>  0
>>>  -----
>>>
>>>  [*] hope this isn't the problem you are mentioning.
>>>
>>> Thanks, Anand