Can I see what device was used to mount btrfs?

[Andrei Borzenkov]

I'm chasing issue with btrfs mounts under systemd
(https://github.com/systemd/systemd/issues/5781) - to summarize, systemd
waits for the final device that makes btrfs complete and mounts it using
this device name. But in /proc/self/mountinfo we actually see another
device name. Due to peculiarities of systemd implementation this device
"does not exist" from systemd PoV.

Looking at btrfs code I start to suspect that we actually do not know
what device was used to mount it at all. I.e.

static int btrfs_show_devname(struct seq_file *m, struct dentry *root)
{
...
while (cur_devices) {
head = _devices->devices;
list_for_each_entry(dev, head, dev_list) {
if (dev->missing)
continue;
if (!dev->name)
continue;
if (!first_dev || dev->devid < first_dev->devid)
first_dev = dev;
}
cur_devices = cur_devices->seed;
}

if (first_dev) {
rcu_read_lock();
name = rcu_dereference(first_dev->name);
seq_escape(m, name->str, " \t\n\\");
rcu_read_unlock();
...


So we always show device with the smallest devid, irrespectively of what
device was actually used to mount it.

Am I correct? What I have here is

localhost:~ # ll /dev/disk/by-label/
total 0
lrwxrwxrwx 1 root root 10 Apr 30 08:03 Storage -> ../../dm-1
localhost:~ # systemctl --no-pager status thin.mount
● thin.mount - /thin
   Loaded: loaded (/etc/fstab; generated; vendor preset: disabled)
   Active: active (mounted) since Sun 2017-04-30 08:03:07 MSK; 6min ago
Where: /thin
 What: /dev/dm-0
 Docs: man:fstab(5)
   man:systemd-fstab-generator(8)
  Process: 982 ExecMount=/usr/bin/mount /dev/disk/by-label/Storage /thin
-t btrfs (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 4915)
   CGroup: /system.slice/thin.mount

Apr 30 08:03:07 localhost systemd[1]: Mounting /thin...
Apr 30 08:03:07 localhost systemd[1]: Mounted /thin.


bur mountinfo shows

localhost:~ # grep /thin /proc/self/mountinfo
96 59 0:63 / /thin rw,relatime shared:47 - btrfs /dev/dm-0
rw,space_cache,subvolid=5,subvol=/

which matches the above algorithm

localhost:~ # btrfs fi show /thin
Label: 'Storage'  uuid: a6f9dd05-460c-418b-83ab-ebdf81f2931a
Total devices 2 FS bytes used 640.00KiB
devid1 size 20.00GiB used 2.01GiB path /dev/mapper/vg01-storage1
devid2 size 10.00GiB used 2.01GiB path /dev/mapper/vg01-storage2

localhost:~ # ll /dev/mapper/
total 0
crw--- 1 root root 10, 236 Apr 30 08:03 control
lrwxrwxrwx 1 root root   7 Apr 30 08:03 vg01-storage1 -> ../dm-0
lrwxrwxrwx 1 root root   7 Apr 30 08:03 vg01-storage2 -> ../dm-1

The original device is presumably stored in kernel somewhere but I do
not know how can I query it?
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

ERROR: cannot find parent subvolume, can't see reason for it.

[J. Hart]

I am trying to do a "send -p src/snp1 src/snp2 dst/" and getting the 
following error:


ERROR: cannot find parent subvolume

The "src/snp1" is present in both "src/" and "dst/".   The "src/snp2" is 
present in "src/" .

The send works when "-p" is not used, but will not work when it is.

I imagine I am missing something obvious but cannot see what, and would 
appreciate some suggestions on what might be causing the error.


note: I have sent several queries to this list, but have not heard 
anything back.   I hope they have not been inappropriate.  If so, I 
would be grateful if you would let me know, or if there is somewhere 
else I should be going for advice.


I have had pretty good luck with the basics of btrfs and have high hopes 
for it.  I do seem to be having some difficulty getting much beyond 
basic functionality with small flat filesystem layouts, and will soon 
have to revert back to ext4 for some of the more complex functionality I 
made use of under that.   I look forward to seeing what further progress 
might be had with btrfs, and hope to be able to use it in a few years time.


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

[PATCH 1/1] btrfs-progs: send: fail on first -ENODATA only

[Christian Brauner]

Returning -ENODATA is only considered invalid on the first run of the loop.

Signed-off-by: Christian Brauner 
---
 cmds-receive.c | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/cmds-receive.c b/cmds-receive.c
index b59f00e4..72e9c8f3 100644
--- a/cmds-receive.c
+++ b/cmds-receive.c
@@ -1091,6 +1091,7 @@ static int do_receive(struct btrfs_receive *rctx, const 
char *tomnt,
char *dest_dir_full_path;
char root_subvol_path[PATH_MAX];
int end = 0;
+   int iterations = 0;
 
dest_dir_full_path = realpath(tomnt, NULL);
if (!dest_dir_full_path) {
@@ -1198,13 +1199,18 @@ static int do_receive(struct btrfs_receive *rctx, const 
char *tomnt,
 rctx,
 rctx->honor_end_cmd,
 max_errors);
-   if (ret < 0 && ret == -ENODATA) {
+   if (ret < 0) {
+   if (ret != -ENODATA)
+   goto out;
+
/* Empty stream is invalid */
-   error("empty stream is not considered valid");
-   ret = -EINVAL;
-   goto out;
-   } else if (ret < 0) {
-   goto out;
+   if (iterations == 0) {
+   error("empty stream is not considered valid");
+   ret = -EINVAL;
+   goto out;
+   }
+
+   ret = 1;
}
if (ret > 0)
end = 1;
@@ -1213,6 +1219,8 @@ static int do_receive(struct btrfs_receive *rctx, const 
char *tomnt,
ret = finish_subvol(rctx);
if (ret < 0)
goto out;
+
+   iterations++;
}
ret = 0;
 
-- 
2.11.0

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

[PATCH 0/1] btrfs-progs: send: fail on first -ENODATA only

[Christian Brauner]

Christian Brauner (1):
  btrfs-progs: send: fail on first -ENODATA only

 cmds-receive.c | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

-- 
2.11.0

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

Re: File system corruption, btrfsck abort

[Chris Murphy]

On Sat, Apr 29, 2017 at 2:46 AM, Christophe de Dinechin
 wrote:

> Are there btrfs commands I could run on a read-only filesystem that would 
> give me this information?

qemu-img info  will give you the status of lazy refcounts.
lsattr will show a capital C in the 3rd to last position if it's nocow
filefrag -v will show many extents with the "unwritten" flag if the
file is fallocated.

$ lsattr
--- ./Desktop
--- ./Downloads
--- ./Templates
--- ./Public
--- ./Documents
--- ./Music
--- ./Pictures
--- ./Videos
c-- ./tmp  ##enable compression
--- ./Applications
C-- ./hello.qcow2   ##this is nocow



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

Re: File system corruption, btrfsck abort

[Chris Murphy]

On Sat, Apr 29, 2017 at 2:46 AM, Christophe de Dinechin
 wrote:
>
>> On 28 Apr 2017, at 22:09, Chris Murphy  wrote:
>>
>> On Fri, Apr 28, 2017 at 3:10 AM, Christophe de Dinechin
>>  wrote:
>>
>>>
>>> QEMU qcow2. Host is BTRFS. Guests are BTRFS, LVM, Ext4, NTFS (winXP and
>>> win10) and HFS+ (macOS Sierra). I think I had 7 VMs installed, planned to
>>> restore another 8 from backups before my previous disk crash. I usually have
>>> at least 2 running, often as many as 5 (fedora, ubuntu, winXP, win10, macOS)
>>> to cover my software testing needs.
>>
>> That is quite a torture test for any file system but more so Btrfs.
>
> Sorry, but could you elaborate why it’s worse for btrfs?


Copy on write. Four of your five guests use non-cow filesystems, so
any overwrite, think journal writes, are new extent writes in Btrfs.
Nothing is overwritten in Btrfs. Only after the write completes are
the stale extents released. So you get a lot of fragmentation, and all
of these tasks you're doing become very metadata heavy workloads.

However, what you're doing should work. The consequence should only be
one of performance, not file system integrity. So your configuration
is useful for testing and making Btrfs better.



>
>> How are the qcow2 files being created?
>
> In most cases, default qcow2 configuration as given by virt-manager.
>
>> What's the qemu-img create
>> command? In particular i'm wondering if these qcow2 files are cow or
>> nocow; if they're compressed by Btrfs; and how many fragments they
>> have with filefrag.
>
> I suspect they are cow. I’ll check (on the other machine with a similar 
> setup) when I’m back home.

Check the qcow2 files with filefrag and see how many extents they
have. I'll bet they're massively fragmented.


>> When I was using qcow2 for backing I used
>>
>> qemu-img create -f qcow2 -o preallocation=falloc,nocow=on,lazy_refcounts=on
>>
>> But then later I started using fallocated raw files with chattr +C
>> applied. And these days I'm just using LVM thin volumes. The journaled
>> file systems in a guest cause a ton of backing file fragmentation
>> unless nocow is used on Btrfs. I've seen hundreds of thousands of
>> extents for a single backing file for a Windows guest.
>
> Are there btrfs commands I could run on a read-only filesystem that would 
> give me this information?

lsattr


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

Re: btrfs, journald logs, fragmentation, and fallocate

[Peter Grandi]

>> [ ... ] these extents are all over the place, they're not
>> contiguous at all. 4K here, 4K there, 4K over there, back to
>> 4K here next to this one, 4K over there...12K over there, 500K
>> unwritten, 4K over there. This seems not so consequential on
>> SSD, [ ... ]

> Indeed there were recent reports that the 'ssd' mount option
> causes that, IIRC by Hans van Kranenburg [ ... ]

The report included news that "sometimes" the 'ssd' option is
automatically switched on at mount even on hard disks. I had
promised to put a summary of the issue on the Btrfs wiki, but
I regret that I haven't yet done that.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: btrfs, journald logs, fragmentation, and fallocate

[Peter Grandi]

> [ ... ] Instead, you can use raw files (preferably sparse unless
> there's both nocow and no snapshots). Btrfs does natively everything
> you'd gain from qcow2, and does it better: you can delete the master
> of a cloned image, deduplicate them, deduplicate two unrelated images;
> you can turn on compression, etc.

Uhm, I understand this argument in the general case (not
specifically as to QCOW2 images), and it has some merit, but it is
"controversial", as there are two counterarguments:

* Application specifici file formats can match better application
  specific requirements.
* Putting advanced functionality into the filesystem code makes it more
  complex and less robust, and Btrfs is a bit of a major example of the
  consequences. I put compression and deduplication as things that I
  reckon make a filesystem too complex.

As to snapshots, I make a difference between filetree snapshots and file
snapshots: the first clones a tree as of the snapshot moment, and it is
a system management feature, the second provides per-file update
rollback. One sort of implies the other, but using the per-file rollback
*systematically*, that is a a feature an application can rely one seems
a bit dangerous to me.

> Once you pay the btrfs performance penalty,

Uhmmm, Btrfs has a small or negative performance penalty as a
general purpose filesystem, and many (more or less well conceived) tests
show it performs up there with the best. The only two real costs I have
to it are the huge CPU cost of doing checksumming all the time, but
that's unavoidable if one wants checksumming, and that checksumming
usually requires metadata duplication, that is at least 'dup' profile
for metadata, and that is indeed a bit expensive.

> you may as well actually use its features,

The features that I think Btrfs gives that are worth using are
checksumming, metadata duplication, and filetree snapshots.

> which make qcow2 redundant and harmful.

My impression is that in almost all cases QCOW2 is harmful, because it
trades more IOPS and complexity for less disk space, and disk space is
cheap and IOPS and complexity are expensive, but of course a lot of
people know better :-). My preferred VM setup is a small essentially
read-only non-QCOW2 image for '/' and everything else mounted via NFSv4,
from the VM host itself or a NAS server, but again lots of people know
better and use multi-terabyte-sized QCOW2 images :-).
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: btrfs check bug

[Jan Köster]

Am Dienstag, 18. April 2017, 21:34:33 CEST schrieben Sie:
> Hi,
> 
> i have to try to create a new extent-tree after checksum error not solveable
> with srub or init-csum-tree. Now i got this failure output from btrfs
> --repair:
>  
> ERROR: errors found in extent allocation tree or chunk allocation
> Fixed 0 roots.
> checking free space cache
> checking fs roots
> root 5 missing its root dir, recreating
> btrfs unable to find ref byte nr 2279425310720 parent 0 root 5  owner 3
> offset 0 btrfs unable to find ref byte nr 2279422181376 parent 0 root 5
>  owner 2 offset 1 btrfs unable to find ref byte nr 2279422672896 parent 0
> root 5  owner 1 offset 1 btrfs unable to find ref byte nr 2279413121024
> parent 0 root 5  owner 0 offset 1 cmds-check.c:3370: check_inode_recs:
> BUG_ON `ret` triggered, value -17 btrfs(+0x50788)[0x5565c775b788]
> btrfs(+0x507db)[0x5565c775b7db]
> btrfs(+0x598e6)[0x5565c77648e6]
> btrfs(cmd_check+0x2bd4)[0x5565c7770185]
> btrfs(main+0x8b)[0x5565c771c0f5]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f76045232b1]
> btrfs(_start+0x2a)[0x5565c771bd7a]
> enabling repair mode
> Checking filesystem on /dev/disk/by-label/home
> UUID: 74454fdd-035b-4a3d-98ec-e38d3e7bcd6b
> cache and super generation don't match, space cache will be invalidated
> Failed to find [2278878576640, 168, 16384]
> Failed to find [2278878593024, 168, 16384]
> Failed to find [2278878609408, 168, 16384]
> Failed to find [2278878625792, 168, 16384]
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

I have try a chunck recover to solve my problem after this i got this error 
with btrfs check:

root@dibsi:/# gdb --args btrfs check /dev/disk/by-label/home 
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from btrfs...done.
(gdb) r
Starting program: /usr/local/bin/btrfs check /dev/disk/by-label/home
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Checking filesystem on /dev/disk/by-label/home
UUID: 74454fdd-035b-4a3d-98ec-e38d3e7bcd6b
checking extents
parent transid verify failed on 2278878494720 wanted 1961093 found 1961096
Ignoring transid failure

Program received signal SIGSEGV, Segmentation fault.
__memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:130
130 ../sysdeps/x86_64/multiarch/memcpy-ssse3.S: Datei oder Verzeichnis 
nicht gefunden.
(gdb) bt
#0  __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:130
#1  0x5557e4ce in memcpy (__len=439, __src=, 
__dest=0x558641c0)
at /usr/include/x86_64-linux-gnu/bits/string3.h:53
#2  read_extent_buffer (eb=eb@entry=0x558292e0, 
dst=dst@entry=0x7fffe3f0, start=, 
len=len@entry=439) at extent_io.c:863
#3  0x555b31e6 in check_chunks_and_extents 
(root=root@entry=0x558641c0) at cmds-check.c:9881
#4  0x555b7240 in cmd_check (argc=, argv=) at cmds-check.c:12977
#5  0x555650f5 in main (argc=2, argv=0x7fffec80) at btrfs.c:246


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

Re: File system corruption, btrfsck abort

[Christophe de Dinechin]

> On 28 Apr 2017, at 22:09, Chris Murphy  wrote:
> 
> On Fri, Apr 28, 2017 at 3:10 AM, Christophe de Dinechin
>  wrote:
> 
>> 
>> QEMU qcow2. Host is BTRFS. Guests are BTRFS, LVM, Ext4, NTFS (winXP and
>> win10) and HFS+ (macOS Sierra). I think I had 7 VMs installed, planned to
>> restore another 8 from backups before my previous disk crash. I usually have
>> at least 2 running, often as many as 5 (fedora, ubuntu, winXP, win10, macOS)
>> to cover my software testing needs.
> 
> That is quite a torture test for any file system but more so Btrfs.

Sorry, but could you elaborate why it’s worse for btrfs?

> How are the qcow2 files being created?

In most cases, default qcow2 configuration as given by virt-manager.

> What's the qemu-img create
> command? In particular i'm wondering if these qcow2 files are cow or
> nocow; if they're compressed by Btrfs; and how many fragments they
> have with filefrag.

I suspect they are cow. I’ll check (on the other machine with a similar setup) 
when I’m back home.


> 
> When I was using qcow2 for backing I used
> 
> qemu-img create -f qcow2 -o preallocation=falloc,nocow=on,lazy_refcounts=on
> 
> But then later I started using fallocated raw files with chattr +C
> applied. And these days I'm just using LVM thin volumes. The journaled
> file systems in a guest cause a ton of backing file fragmentation
> unless nocow is used on Btrfs. I've seen hundreds of thousands of
> extents for a single backing file for a Windows guest.

Are there btrfs commands I could run on a read-only filesystem that would give 
me this information?

Thanks
Christophe

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

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

Re: btrfs check bug

[Jan Köster]

Am Dienstag, 18. April 2017, 21:34:33 CEST schrieben Sie:
> Hi,
> 
> i have to try to create a new extent-tree after checksum error not solveable
> with srub or init-csum-tree. Now i got this failure output from btrfs
> --repair:
>  
> ERROR: errors found in extent allocation tree or chunk allocation
> Fixed 0 roots.
> checking free space cache
> checking fs roots
> root 5 missing its root dir, recreating
> btrfs unable to find ref byte nr 2279425310720 parent 0 root 5  owner 3
> offset 0 btrfs unable to find ref byte nr 2279422181376 parent 0 root 5
>  owner 2 offset 1 btrfs unable to find ref byte nr 2279422672896 parent 0
> root 5  owner 1 offset 1 btrfs unable to find ref byte nr 2279413121024
> parent 0 root 5  owner 0 offset 1 cmds-check.c:3370: check_inode_recs:
> BUG_ON `ret` triggered, value -17 btrfs(+0x50788)[0x5565c775b788]
> btrfs(+0x507db)[0x5565c775b7db]
> btrfs(+0x598e6)[0x5565c77648e6]
> btrfs(cmd_check+0x2bd4)[0x5565c7770185]
> btrfs(main+0x8b)[0x5565c771c0f5]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f76045232b1]
> btrfs(_start+0x2a)[0x5565c771bd7a]
> enabling repair mode
> Checking filesystem on /dev/disk/by-label/home
> UUID: 74454fdd-035b-4a3d-98ec-e38d3e7bcd6b
> cache and super generation don't match, space cache will be invalidated
> Failed to find [2278878576640, 168, 16384]
> Failed to find [2278878593024, 168, 16384]
> Failed to find [2278878609408, 168, 16384]
> Failed to find [2278878625792, 168, 16384]
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

I have try a chunck recover to solve my problem after this i got this error 
with btrfs check:

root@dibsi:/# gdb --args btrfs check /dev/disk/by-label/home 
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from btrfs...done.
(gdb) r
Starting program: /usr/local/bin/btrfs check /dev/disk/by-label/home
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Checking filesystem on /dev/disk/by-label/home
UUID: 74454fdd-035b-4a3d-98ec-e38d3e7bcd6b
checking extents
parent transid verify failed on 2278878494720 wanted 1961093 found 1961096
Ignoring transid failure

Program received signal SIGSEGV, Segmentation fault.
__memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:130
130 ../sysdeps/x86_64/multiarch/memcpy-ssse3.S: Datei oder Verzeichnis 
nicht gefunden.
(gdb) bt
#0  __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:130
#1  0x5557e4ce in memcpy (__len=439, __src=, 
__dest=0x558641c0)
at /usr/include/x86_64-linux-gnu/bits/string3.h:53
#2  read_extent_buffer (eb=eb@entry=0x558292e0, 
dst=dst@entry=0x7fffe3f0, start=, 
len=len@entry=439) at extent_io.c:863
#3  0x555b31e6 in check_chunks_and_extents 
(root=root@entry=0x558641c0) at cmds-check.c:9881
#4  0x555b7240 in cmd_check (argc=, argv=) at cmds-check.c:12977
#5  0x555650f5 in main (argc=2, argv=0x7fffec80) at btrfs.c:246


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

Re: [PATCH] btrfs: check options during subsequent mount

[Anand Jain]

On 04/29/2017 01:26 PM, Andrei Borzenkov wrote:

28.04.2017 12:14, Anand Jain пишет:

We allow recursive mounts with subvol options such as [1]

[1]
 mount -o rw,compress=lzo /dev/sdc /btrfs1
 mount -o ro,subvol=sv2 /dev/sdc /btrfs2

And except for the btrfs-specific subvol and subvolid options
all-other options are just ignored in the subsequent mounts.

In the below example [2] the effect compression is only zlib,
even though there was no error for the option -o compress=lzo.

[2]

 # mount -o compress=zlib /dev/sdc /btrfs1
 #echo $?
 0

 # mount -o compress=lzo /dev/sdc /btrfs
 #echo $?
 0

 #cat /proc/self/mounts
 ::
 /dev/sdc /btrfs1 btrfs 
rw,relatime,compress=zlib,space_cache,subvolid=5,subvol=/ 0 0
 /dev/sdc /btrfs btrfs 
rw,relatime,compress=zlib,space_cache,subvolid=5,subvol=/ 0 0


Further, random string .. has no error as well.
-
 # mount -o compress=zlib /dev/sdc /btrfs1
 #echo $?
 0

 # mount -o something /dev/sdc /btrfs
 #echo $?
 0
-

This patch fixes the above issue, by checking the if the passed
options are only subvol or subvolid in the subsequent mount.

Signed-off-by: Anand Jain 
---
 fs/btrfs/super.c | 40 
 1 file changed, 40 insertions(+)

diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 9530a333d302..e0e542345c38 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -389,6 +389,44 @@ static const match_table_t tokens = {
{Opt_err, NULL},
 };

+static int parse_recursive_mount_options(char *data)
+{
+   substring_t args[MAX_OPT_ARGS];
+   char *options, *orig;
+   char *p;
+   int ret = 0;
+
+   /*
+* This is not a remount thread, but we allow recursive mounts
+* with varying RO/RW flag to support subvol-mounts. So error-out
+* if any other option being passed in here.
+*/
+
+   options = kstrdup(data, GFP_NOFS);
+   if (!options)
+   return -ENOMEM;
+
+   orig = options;
+
+   while ((p = strsep(, ",")) != NULL) {
+   int token;
+   if (!*p)
+   continue;
+
+   token = match_token(p, tokens, args);
+   switch(token) {
+   case Opt_subvol:
+   case Opt_subvolid:
+   break;
+   default:
+   ret = -EBUSY;
+   }
+   }
+
+   kfree(orig);
+   return ret;
+}
+
 /*
  * Regular mount options parser.  Everything that is needed only when
  * reading in a new superblock is parsed here.
@@ -1611,6 +1649,8 @@ static struct dentry *btrfs_mount(struct file_system_type 
*fs_type, int flags,
free_fs_info(fs_info);
if ((flags ^ s->s_flags) & MS_RDONLY)
error = -EBUSY;
+   if (parse_recursive_mount_options(data))
+   error = -EBUSY;


But if subvol= was passed, it should not reach this place at all -
btrfs_mount() returns earlier in

if (subvol_name || subvol_objectid != BTRFS_FS_TREE_OBJECTID) {
/* mount_subvol() will free subvol_name. */
return mount_subvol(subvol_name, subvol_objectid, flags,
device_name, data);
}

So check for subvol here seems redundant.


Thanks for the review.

No its not, actually mount_subvol() will call vfs_kern_mount() which
will call out our mount entry point btrfs_mount() with subvolid=0,
and btrfs_parse_early_options() will set subvolid=5, which then
fails the check and goes to the rest of the code in btrfs_mount().

HTH.

Thanks, Anand




} else {
snprintf(s->s_id, sizeof(s->s_id), "%pg", bdev);
btrfs_sb(s)->bdev_holder = fs_type;



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


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