linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* btrfs fi du -s gives Inappropriate ioctl for device
@ 2017-08-14 22:57 Piotr Szymaniak
  2017-08-14 23:40 ` Chris Murphy
  2017-08-17 15:37 ` Goffredo Baroncelli
  0 siblings, 2 replies; 12+ messages in thread
From: Piotr Szymaniak @ 2017-08-14 22:57 UTC (permalink / raw)
  To: linux-btrfs

[-- Attachment #1: Type: text/plain, Size: 2957 bytes --]

Hi list,

I have some weird issue.

So, I have btrfs fs and some subvols, like that:
~ # btrfs sub list /mnt/red/
ID 260 gen 827956 top level 5 path @home
ID 261 gen 827926 top level 5 path @backup
ID 645 gen 827911 top level 5 path @svn
*snip*

and some snapshots on those subvols:
*snip*
ID 2501 gen 827894 top level 260 path @home/.snapshot/monthly_2017-05-01_05:30:01
ID 2603 gen 827894 top level 260 path @home/.snapshot/monthly_2017-06-01_05:30:01
ID 2604 gen 827927 top level 261 path @backup/.snapshot/monthly_2017-06-01_05:30:02
ID 2680 gen 827895 top level 260 path @home/.snapshot/monthly_2017-07-01_05:30:01
ID 2681 gen 827927 top level 261 path @backup/.snapshot/monthly_2017-07-01_05:30:01
ID 2734 gen 827895 top level 260 path @home/.snapshot/weekly_2017-07-22_04:20:01
ID 2735 gen 827905 top level 645 path @svn/.snapshot/weekly_2017-07-22_04:20:02
ID 2754 gen 827895 top level 260 path @home/.snapshot/weekly_2017-07-29_04:20:01
ID 2755 gen 827906 top level 645 path @svn/.snapshot/weekly_2017-07-29_04:20:01
ID 2763 gen 827896 top level 260 path @home/.snapshot/monthly_2017-08-01_05:30:01
*snip*

and... some issues:
~ # btrfs fi du -s /mnt/red/\@backup/
     Total   Exclusive  Set shared  Filename
ERROR: cannot check space of '/mnt/red/@backup/': Inappropriate ioctl for device

and it works for other subvols:
~ # btrfs fi du -s /mnt/red/\@svn/
     Total   Exclusive  Set shared  Filename
  52.22GiB    10.59MiB     4.13GiB  /mnt/red/@svn/

~ # btrfs fi du -s /mnt/red/\@home/
     Total   Exclusive  Set shared  Filename
   2.08TiB     4.54GiB   124.51GiB  /mnt/red/@home/

on the other hand, those values also look wrong (2.08TiB?):
~ # btrfs fi df /mnt/red/\@home/
Data, RAID1: total=448.00GiB, used=447.39GiB
System, RAID1: total=32.00MiB, used=80.00KiB
Metadata, RAID1: total=3.00GiB, used=2.02GiB
GlobalReserve, single: total=512.00MiB, used=0.00B

~ # btrfs fi usage /mnt/red/\@home/
Overall:
    Device size:                   1.36TiB
    Device allocated:            902.06GiB
    Device unallocated:          493.21GiB
    Device missing:                  0.00B
    Used:                        898.81GiB
    Free (estimated):            247.22GiB      (min: 247.22GiB)
    Data ratio:                       2.00
    Metadata ratio:                   2.00
    Global reserve:              512.00MiB      (used: 0.00B)

Data,RAID1: Size:448.00GiB, Used:447.39GiB
   /dev/mapper/wd0       448.00GiB
   /dev/mapper/wd1       448.00GiB

Metadata,RAID1: Size:3.00GiB, Used:2.02GiB
   /dev/mapper/wd0         3.00GiB
   /dev/mapper/wd1         3.00GiB

System,RAID1: Size:32.00MiB, Used:80.00KiB
   /dev/mapper/wd0        32.00MiB
   /dev/mapper/wd1        32.00MiB

Unallocated:
   /dev/mapper/wd0       246.60GiB
   /dev/mapper/wd1       246.60GiB

~ # uname -sr
Linux 4.4.76

~ # btrfs --version
btrfs-progs v4.12

Whats wrong with one of my subvols? Whats wrong with space reported by fi du?


Best regards,
Piotr Szymaniak.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: btrfs fi du -s gives Inappropriate ioctl for device
  2017-08-14 22:57 btrfs fi du -s gives Inappropriate ioctl for device Piotr Szymaniak
@ 2017-08-14 23:40 ` Chris Murphy
  2017-08-16  9:27   ` Piotr Szymaniak
  2017-08-17 15:37 ` Goffredo Baroncelli
  1 sibling, 1 reply; 12+ messages in thread
From: Chris Murphy @ 2017-08-14 23:40 UTC (permalink / raw)
  To: Piotr Szymaniak; +Cc: Btrfs BTRFS

On Mon, Aug 14, 2017 at 4:57 PM, Piotr Szymaniak <szarpaj@grubelek.pl> wrote:

>
> and... some issues:
> ~ # btrfs fi du -s /mnt/red/\@backup/
>      Total   Exclusive  Set shared  Filename
> ERROR: cannot check space of '/mnt/red/@backup/': Inappropriate ioctl for device


It's a bug, but I don't know if any devs are working on a fix yet.

The problem is that the subvolume being snapshot, contains subvolumes.
The resulting snapshot, contains an empty directory in place of the
nested subvolume(s), and that is the cause for the error.


Other messages on this:
https://www.spinics.net/lists/linux-btrfs/msg67330.html
https://www.spinics.net/lists/linux-btrfs/msg61883.html



-- 
Chris Murphy

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: btrfs fi du -s gives Inappropriate ioctl for device
  2017-08-14 23:40 ` Chris Murphy
@ 2017-08-16  9:27   ` Piotr Szymaniak
  2017-08-17  0:23     ` Chris Murphy
  0 siblings, 1 reply; 12+ messages in thread
From: Piotr Szymaniak @ 2017-08-16  9:27 UTC (permalink / raw)
  To: Chris Murphy; +Cc: Btrfs BTRFS

[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]

On Mon, Aug 14, 2017 at 05:40:30PM -0600, Chris Murphy wrote:
> On Mon, Aug 14, 2017 at 4:57 PM, Piotr Szymaniak <szarpaj@grubelek.pl> wrote:
> 
> >
> > and... some issues:
> > ~ # btrfs fi du -s /mnt/red/\@backup/
> >      Total   Exclusive  Set shared  Filename
> > ERROR: cannot check space of '/mnt/red/@backup/': Inappropriate ioctl for device
> 
> 
> It's a bug, but I don't know if any devs are working on a fix yet.
> 
> The problem is that the subvolume being snapshot, contains subvolumes.
> The resulting snapshot, contains an empty directory in place of the
> nested subvolume(s), and that is the cause for the error.

Ok, but why, on the same btrfs, it works on some subvols with subvols and does
not work on other subvols with subvols? If it does not work - OK, if it works -
OK, but that seems a bit... random?

~ # btrfs fi du -s /mnt/red/\@backup/ /mnt/red/\@backup/.snapshot/monthly_2017-08-01_05\:30\:01/ /mnt/red/\@svn/ /mnt/red/\@svn/.snapshot/weekly_2017-08-05_04\:20\:02/
     Total   Exclusive  Set shared  Filename
ERROR: cannot check space of '/mnt/red/@backup/': Inappropriate ioctl for device
ERROR: cannot check space of '/mnt/red/@backup/.snapshot/monthly_2017-08-01_05:30:01/': Inappropriate ioctl for device
  52.23GiB    10.57MiB     4.13GiB  /mnt/red/@svn/
   4.35GiB     1.03MiB     4.12GiB  /mnt/red/@svn/.snapshot/weekly_2017-08-05_04:20:02/


Best regards,
Piotr Szymaniak.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: btrfs fi du -s gives Inappropriate ioctl for device
  2017-08-16  9:27   ` Piotr Szymaniak
@ 2017-08-17  0:23     ` Chris Murphy
  0 siblings, 0 replies; 12+ messages in thread
From: Chris Murphy @ 2017-08-17  0:23 UTC (permalink / raw)
  To: Piotr Szymaniak; +Cc: Chris Murphy, Btrfs BTRFS

On Wed, Aug 16, 2017 at 3:27 AM, Piotr Szymaniak <szarpaj@grubelek.pl> wrote:
> On Mon, Aug 14, 2017 at 05:40:30PM -0600, Chris Murphy wrote:
>> On Mon, Aug 14, 2017 at 4:57 PM, Piotr Szymaniak <szarpaj@grubelek.pl> wrote:
>>
>> >
>> > and... some issues:
>> > ~ # btrfs fi du -s /mnt/red/\@backup/
>> >      Total   Exclusive  Set shared  Filename
>> > ERROR: cannot check space of '/mnt/red/@backup/': Inappropriate ioctl for device
>>
>>
>> It's a bug, but I don't know if any devs are working on a fix yet.
>>
>> The problem is that the subvolume being snapshot, contains subvolumes.
>> The resulting snapshot, contains an empty directory in place of the
>> nested subvolume(s), and that is the cause for the error.
>
> Ok, but why, on the same btrfs, it works on some subvols with subvols and does
> not work on other subvols with subvols? If it does not work - OK, if it works -
> OK, but that seems a bit... random?
>
> ~ # btrfs fi du -s /mnt/red/\@backup/ /mnt/red/\@backup/.snapshot/monthly_2017-08-01_05\:30\:01/ /mnt/red/\@svn/ /mnt/red/\@svn/.snapshot/weekly_2017-08-05_04\:20\:02/
>      Total   Exclusive  Set shared  Filename
> ERROR: cannot check space of '/mnt/red/@backup/': Inappropriate ioctl for device
> ERROR: cannot check space of '/mnt/red/@backup/.snapshot/monthly_2017-08-01_05:30:01/': Inappropriate ioctl for device
>   52.23GiB    10.57MiB     4.13GiB  /mnt/red/@svn/
>    4.35GiB     1.03MiB     4.12GiB  /mnt/red/@svn/.snapshot/weekly_2017-08-05_04:20:02/

I don't know.

 It might be that there's something inconsistent about the inode for
the missing/ghost subvolume placeholder directory at snapshot creation
time?

-- 
Chris Murphy

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: btrfs fi du -s gives Inappropriate ioctl for device
  2017-08-14 22:57 btrfs fi du -s gives Inappropriate ioctl for device Piotr Szymaniak
  2017-08-14 23:40 ` Chris Murphy
@ 2017-08-17 15:37 ` Goffredo Baroncelli
  2017-08-17 18:43   ` Chris Murphy
  1 sibling, 1 reply; 12+ messages in thread
From: Goffredo Baroncelli @ 2017-08-17 15:37 UTC (permalink / raw)
  To: Piotr Szymaniak, linux-btrfs

Hi,

On 08/15/2017 12:57 AM, Piotr Szymaniak wrote:
> and... some issues:
> ~ # btrfs fi du -s /mnt/red/\@backup/
>      Total   Exclusive  Set shared  Filename
> ERROR: cannot check space of '/mnt/red/@backup/': Inappropriate ioctl for device


could you share the output of 

strace btrfs fi du -s /mnt/red/\@backup/

this shouldn't  contain sensible information

BR
G.Baroncelli

-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: btrfs fi du -s gives Inappropriate ioctl for device
  2017-08-17 15:37 ` Goffredo Baroncelli
@ 2017-08-17 18:43   ` Chris Murphy
  2017-08-17 20:59     ` Goffredo Baroncelli
  0 siblings, 1 reply; 12+ messages in thread
From: Chris Murphy @ 2017-08-17 18:43 UTC (permalink / raw)
  To: Goffredo Baroncelli; +Cc: Piotr Szymaniak, Btrfs BTRFS

# btrfs sub create test1
Create subvolume './test1'
# btrfs sub create test1/test2
Create subvolume 'test1/test2'
# btrfs sub snap test1 test1.snap
Create a snapshot of 'test1' in './test1.snap'
# btrfs fi du -s test1
     Total   Exclusive  Set shared  Filename
     0.00B       0.00B       0.00B  test1
# btrfs fi du -s test1.snap
     Total   Exclusive  Set shared  Filename
ERROR: cannot check space of 'test1.snap': Inappropriate ioctl for device
#


Pretty strace here:
https://pastebin.com/raw/ibnha9Sx


Ugly MUA strace here for the archive:


# strace btrfs fi du -s test1.snap
execve("/sbin/btrfs", ["btrfs", "fi", "du", "-s", "test1.snap"],
0x7fff8c0af970 /* 32 vars */) = 0
brk(NULL)                               = 0xa96a201000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f84880a4000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=104181, ...}) = 0
mmap(NULL, 104181, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f848808a000
close(3)                                = 0
open("/lib64/libuuid.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\23\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=19568, ...}) = 0
mmap(NULL, 2113552, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7f8487c7b000
mprotect(0x7f8487c7f000, 2093056, PROT_NONE) = 0
mmap(0x7f8487e7e000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7f8487e7e000
mmap(0x7f8487e7f000, 16, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f8487e7f000
close(3)                                = 0
open("/lib64/libblkid.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\227\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=304792, ...}) = 0
mmap(NULL, 2397952, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7f8487a31000
mprotect(0x7f8487a75000, 2093056, PROT_NONE) = 0
mmap(0x7f8487c74000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x43000) = 0x7f8487c74000
mmap(0x7f8487c7a000, 1792, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f8487c7a000
close(3)                                = 0
open("/lib64/libz.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\"\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=94104, ...}) = 0
mmap(NULL, 2187272, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7f848781a000
mprotect(0x7f8487830000, 2093056, PROT_NONE) = 0
mmap(0x7f8487a2f000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15000) = 0x7f8487a2f000
mmap(0x7f8487a30000, 8, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f8487a30000
close(3)                                = 0
open("/lib64/liblzo2.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320$\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=138800, ...}) = 0
mmap(NULL, 2232328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7f84875f8000
mprotect(0x7f8487619000, 2093056, PROT_NONE) = 0
mmap(0x7f8487818000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x20000) = 0x7f8487818000
mmap(0x7f8487819000, 8, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f8487819000
close(3)                                = 0
open("/lib64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340^\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=153896, ...}) = 0
mmap(NULL, 2220552, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7f84873d9000
mprotect(0x7f84873f2000, 2097152, PROT_NONE) = 0
mmap(0x7f84875f2000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19000) = 0x7f84875f2000
mmap(0x7f84875f4000, 12808, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f84875f4000
close(3)                                = 0
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\5\2\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=2163104, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f8488088000
mmap(NULL, 4000096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7f8487008000
mprotect(0x7f84871cf000, 2097152, PROT_NONE) = 0
mmap(0x7f84873cf000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1c7000) = 0x7f84873cf000
mmap(0x7f84873d5000, 14688, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f84873d5000
close(3)                                = 0
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f8488085000
arch_prctl(ARCH_SET_FS, 0x7f84880858c0) = 0
mprotect(0x7f84873cf000, 16384, PROT_READ) = 0
mprotect(0x7f84875f2000, 4096, PROT_READ) = 0
mprotect(0x7f8487818000, 4096, PROT_READ) = 0
mprotect(0x7f8487a2f000, 4096, PROT_READ) = 0
mprotect(0x7f8487e7e000, 4096, PROT_READ) = 0
mprotect(0x7f8487c74000, 20480, PROT_READ) = 0
mprotect(0xa968435000, 20480, PROT_READ) = 0
mprotect(0x7f84880a6000, 4096, PROT_READ) = 0
munmap(0x7f848808a000, 104181)          = 0
set_tid_address(0x7f8488085b90)         = 13929
set_robust_list(0x7f8488085ba0, 24)     = 0
rt_sigaction(SIGRTMIN, {sa_handler=0x7f84873de960, sa_mask=[],
sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7f84873eb2c0}, NULL, 8)
= 0
rt_sigaction(SIGRT_1, {sa_handler=0x7f84873dea00, sa_mask=[],
sa_flags=SA_RESTORER|SA_RESTART|SA_SIGINFO,
sa_restorer=0x7f84873eb2c0}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024,
rlim_max=RLIM64_INFINITY}) = 0
uname({sysname="Linux", nodename="f26h.localdomain", ...}) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
brk(NULL)                               = 0xa96a201000
brk(0xa96a222000)                       = 0xa96a222000
brk(NULL)                               = 0xa96a222000
write(1, "     Total   Exclusive  Set shar"..., 45     Total
Exclusive  Set shared  Filename
) = 45
newfstatat(AT_FDCWD, "test1.snap", {st_mode=S_IFDIR|0755, st_size=10,
...}, 0) = 0
stat("test1.snap", {st_mode=S_IFDIR|0755, st_size=10, ...}) = 0
open("test1.snap", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFDIR|0755, st_size=10, ...}) = 0
ioctl(3, BTRFS_IOC_INO_LOOKUP, {treeid=0, objectid=256 /*
BTRFS_FIRST_FREE_OBJECTID */} => {treeid=486, name=""}) = 0
getdents(3, /* 3 entries */, 32768)     = 80
newfstatat(3, "test2", {st_mode=S_IFDIR|0755, st_size=0, ...}, 0) = 0
stat("test1.snap/test2", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
open("test1.snap/test2", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4
fstat(4, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
ioctl(4, BTRFS_IOC_INO_LOOKUP, {treeid=0, objectid=256 /*
BTRFS_FIRST_FREE_OBJECTID */}) = -1 ENOTTY (Inappropriate ioctl for
device)
close(4)                                = 0
getdents(3, /* 0 entries */, 32768)     = 0
close(3)                                = 0
write(2, "ERROR: ", 7ERROR: )                  = 7
write(2, "cannot check space of 'test1.sna"..., 66cannot check space
of 'test1.snap': Inappropriate ioctl for device) = 66
write(2, "\n", 1
)                       = 1
exit_group(1)                           = ?
+++ exited with 1 +++
#


# uname -r
4.13.0-0.rc4.git1.1.fc27.x86_64
# rpm -q btrfs-progs
btrfs-progs-4.12-1.fc27.x86_64


----
Chris Murphy

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: btrfs fi du -s gives Inappropriate ioctl for device
  2017-08-17 18:43   ` Chris Murphy
@ 2017-08-17 20:59     ` Goffredo Baroncelli
  2017-08-18  6:34       ` Nikolay Borisov
  2017-08-18  8:38       ` Piotr Szymaniak
  0 siblings, 2 replies; 12+ messages in thread
From: Goffredo Baroncelli @ 2017-08-17 20:59 UTC (permalink / raw)
  To: Chris Murphy; +Cc: Piotr Szymaniak, Btrfs BTRFS

Hi,

On 08/17/2017 08:43 PM, Chris Murphy wrote:
> # btrfs sub create test1
> Create subvolume './test1'
> # btrfs sub create test1/test2
> Create subvolume 'test1/test2'
> # btrfs sub snap test1 test1.snap
> Create a snapshot of 'test1' in './test1.snap'
> # btrfs fi du -s test1
>      Total   Exclusive  Set shared  Filename
>      0.00B       0.00B       0.00B  test1
> # btrfs fi du -s test1.snap
>      Total   Exclusive  Set shared  Filename
> ERROR: cannot check space of 'test1.snap': Inappropriate ioctl for device
> #
> 

tanks for the test case. Now I was able to reproduce the problem. The bug(s) are two:

1) to get the treeid of the files/directory, the function lookup_path_rootid() is used, which behaves strangely when it is called on a directory that is BTRFS_EMPTY_SUBVOL_DIR_OBJECTID. In fact this function is commented as following:
[....]
/*
 * For a given:
 * - file or directory return the containing tree root id
 * - subvolume return its own tree id
 * - BTRFS_EMPTY_SUBVOL_DIR_OBJECTID (directory with ino == 2) the result is
 *   undefined and function returns -1
 */
int lookup_path_rootid(int fd, u64 *rootid)
{
[....]

The caller (du_add_file()) doesn't consider this case.

2) in the function du_walk_dir(), an error returned by du_add_file() is ignored, but the return value is not reset. So if the last entry has ino BTRFS_EMPTY_SUBVOL_DIR_OBJECTID (directory with ino == 2) an error is returned. But if there is another directory item no error is returned !

See the following tests cases:

# btrfs sub create test1
# btrfs sub create test1/test2
# btrfs sub snap test1 test1.snap
# btrfs fi du -s test1
     Total   Exclusive  Set shared  Filename
     0.00B       0.00B       0.00B  test1
# btrfs fi du -s test1.snap
     Total   Exclusive  Set shared  Filename
ERROR: cannot check space of 'test1.snap': Inappropriate ioctl for device

But if you add *another* file/dir in test1.snap you got:

# mkdir test1.snap/dir
# btrfs fi du -s test1.snap
     Total   Exclusive  Set shared  Filename
     0.00B       0.00B       0.00B  test1.snap

The error disappear !

Patches will follow shortly

> 
> # uname -r
> 4.13.0-0.rc4.git1.1.fc27.x86_64
> # rpm -q btrfs-progs
> btrfs-progs-4.12-1.fc27.x86_64
> 
> 
> ----
> Chris Murphy
> 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: btrfs fi du -s gives Inappropriate ioctl for device
  2017-08-17 20:59     ` Goffredo Baroncelli
@ 2017-08-18  6:34       ` Nikolay Borisov
  2017-08-18  7:09         ` Goffredo Baroncelli
  2017-08-18  8:38       ` Piotr Szymaniak
  1 sibling, 1 reply; 12+ messages in thread
From: Nikolay Borisov @ 2017-08-18  6:34 UTC (permalink / raw)
  To: kreijack, Chris Murphy; +Cc: Piotr Szymaniak, Btrfs BTRFS



On 17.08.2017 23:59, Goffredo Baroncelli wrote:
> Hi,
> 
> On 08/17/2017 08:43 PM, Chris Murphy wrote:
>> # btrfs sub create test1
>> Create subvolume './test1'
>> # btrfs sub create test1/test2
>> Create subvolume 'test1/test2'
>> # btrfs sub snap test1 test1.snap
>> Create a snapshot of 'test1' in './test1.snap'
>> # btrfs fi du -s test1
>>      Total   Exclusive  Set shared  Filename
>>      0.00B       0.00B       0.00B  test1
>> # btrfs fi du -s test1.snap
>>      Total   Exclusive  Set shared  Filename
>> ERROR: cannot check space of 'test1.snap': Inappropriate ioctl for device
>> #
>>
> 
> tanks for the test case. Now I was able to reproduce the problem. The bug(s) are two:
> 
> 1) to get the treeid of the files/directory, the function lookup_path_rootid() is used, which behaves strangely when it is called on a directory that is BTRFS_EMPTY_SUBVOL_DIR_OBJECTID. In fact this function is commented as following:
> [....]
> /*
>  * For a given:
>  * - file or directory return the containing tree root id
>  * - subvolume return its own tree id
>  * - BTRFS_EMPTY_SUBVOL_DIR_OBJECTID (directory with ino == 2) the result is
>  *   undefined and function returns -1
>  */
> int lookup_path_rootid(int fd, u64 *rootid)
> {
> [....]
> 
> The caller (du_add_file()) doesn't consider this case.
> 
> 2) in the function du_walk_dir(), an error returned by du_add_file() is ignored, but the return value is not reset. So if the last entry has ino BTRFS_EMPTY_SUBVOL_DIR_OBJECTID (directory with ino == 2) an error is returned. But if there is another directory item no error is returned !
> 
> See the following tests cases:
> 
> # btrfs sub create test1
> # btrfs sub create test1/test2
> # btrfs sub snap test1 test1.snap
> # btrfs fi du -s test1
>      Total   Exclusive  Set shared  Filename
>      0.00B       0.00B       0.00B  test1
> # btrfs fi du -s test1.snap
>      Total   Exclusive  Set shared  Filename
> ERROR: cannot check space of 'test1.snap': Inappropriate ioctl for device
> 
> But if you add *another* file/dir in test1.snap you got:
> 
> # mkdir test1.snap/dir
> # btrfs fi du -s test1.snap
>      Total   Exclusive  Set shared  Filename
>      0.00B       0.00B       0.00B  test1.snap
> 
> The error disappea> Patches will follow shortly

It would be awesome if you manage to introduce xfstests for this case

> 
>>
>> # uname -r
>> 4.13.0-0.rc4.git1.1.fc27.x86_64
>> # rpm -q btrfs-progs
>> btrfs-progs-4.12-1.fc27.x86_64
>>
>>
>> ----
>> Chris Murphy
>>
> 
> 

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: btrfs fi du -s gives Inappropriate ioctl for device
  2017-08-18  6:34       ` Nikolay Borisov
@ 2017-08-18  7:09         ` Goffredo Baroncelli
  2017-08-18  7:12           ` Nikolay Borisov
  0 siblings, 1 reply; 12+ messages in thread
From: Goffredo Baroncelli @ 2017-08-18  7:09 UTC (permalink / raw)
  To: Nikolay Borisov; +Cc: Chris Murphy, Piotr Szymaniak, Btrfs BTRFS

On 08/18/2017 08:34 AM, Nikolay Borisov wrote:
> 
> 
> On 17.08.2017 23:59, Goffredo Baroncelli wrote:
>> Hi,
>>
>> On 08/17/2017 08:43 PM, Chris Murphy wrote:
>>> # btrfs sub create test1
>>> Create subvolume './test1'
>>> # btrfs sub create test1/test2
>>> Create subvolume 'test1/test2'
>>> # btrfs sub snap test1 test1.snap
>>> Create a snapshot of 'test1' in './test1.snap'
>>> # btrfs fi du -s test1
>>>      Total   Exclusive  Set shared  Filename
>>>      0.00B       0.00B       0.00B  test1
>>> # btrfs fi du -s test1.snap
>>>      Total   Exclusive  Set shared  Filename
>>> ERROR: cannot check space of 'test1.snap': Inappropriate ioctl for device
>>> #
>>>
>>
>> tanks for the test case. Now I was able to reproduce the problem. The bug(s) are two:
>>
>> 1) to get the treeid of the files/directory, the function lookup_path_rootid() is used, which behaves strangely when it is called on a directory that is BTRFS_EMPTY_SUBVOL_DIR_OBJECTID. In fact this function is commented as following:
>> [....]
>> /*
>>  * For a given:
>>  * - file or directory return the containing tree root id
>>  * - subvolume return its own tree id
>>  * - BTRFS_EMPTY_SUBVOL_DIR_OBJECTID (directory with ino == 2) the result is
>>  *   undefined and function returns -1
>>  */
>> int lookup_path_rootid(int fd, u64 *rootid)
>> {
>> [....]
>>
>> The caller (du_add_file()) doesn't consider this case.
>>
>> 2) in the function du_walk_dir(), an error returned by du_add_file() is ignored, but the return value is not reset. So if the last entry has ino BTRFS_EMPTY_SUBVOL_DIR_OBJECTID (directory with ino == 2) an error is returned. But if there is another directory item no error is returned !
>>
>> See the following tests cases:
>>
>> # btrfs sub create test1
>> # btrfs sub create test1/test2
>> # btrfs sub snap test1 test1.snap
>> # btrfs fi du -s test1
>>      Total   Exclusive  Set shared  Filename
>>      0.00B       0.00B       0.00B  test1
>> # btrfs fi du -s test1.snap
>>      Total   Exclusive  Set shared  Filename
>> ERROR: cannot check space of 'test1.snap': Inappropriate ioctl for device
>>
>> But if you add *another* file/dir in test1.snap you got:
>>
>> # mkdir test1.snap/dir
>> # btrfs fi du -s test1.snap
>>      Total   Exclusive  Set shared  Filename
>>      0.00B       0.00B       0.00B  test1.snap
>>
>> The error disappea> Patches will follow shortly
> 
> It would be awesome if you manage to introduce xfstests for this case

I am not sure if this is the right thing to do: the bugs are related to 
a) an incorrect error handling of the function lookup_path_rootid()
b) the strange behavior of the BTRFS_EMPTY_SUBVOL_DIR_OBJECTID directory

For a) it is impossible to check for each lookup_path_rootid() call from a xfstest; for b) I am quite sure that there are a lot of corner case not properly handled in btrfs progs (and still btrfs fi-du handle it wrongly)

BR
G.Baroncelli

> 
>>
>>>
>>> # uname -r
>>> 4.13.0-0.rc4.git1.1.fc27.x86_64
>>> # rpm -q btrfs-progs
>>> btrfs-progs-4.12-1.fc27.x86_64
>>>
>>>
>>> ----
>>> Chris Murphy
>>>
>>
>>
> --
> 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
> 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: btrfs fi du -s gives Inappropriate ioctl for device
  2017-08-18  7:09         ` Goffredo Baroncelli
@ 2017-08-18  7:12           ` Nikolay Borisov
  2017-08-18  7:22             ` Goffredo Baroncelli
  0 siblings, 1 reply; 12+ messages in thread
From: Nikolay Borisov @ 2017-08-18  7:12 UTC (permalink / raw)
  To: kreijack; +Cc: Chris Murphy, Piotr Szymaniak, Btrfs BTRFS



On 18.08.2017 10:09, Goffredo Baroncelli wrote:
> On 08/18/2017 08:34 AM, Nikolay Borisov wrote:
>>
>>
>> On 17.08.2017 23:59, Goffredo Baroncelli wrote:
>>> Hi,
>>>
>>> On 08/17/2017 08:43 PM, Chris Murphy wrote:
>>>> # btrfs sub create test1
>>>> Create subvolume './test1'
>>>> # btrfs sub create test1/test2
>>>> Create subvolume 'test1/test2'
>>>> # btrfs sub snap test1 test1.snap
>>>> Create a snapshot of 'test1' in './test1.snap'
>>>> # btrfs fi du -s test1
>>>>      Total   Exclusive  Set shared  Filename
>>>>      0.00B       0.00B       0.00B  test1
>>>> # btrfs fi du -s test1.snap
>>>>      Total   Exclusive  Set shared  Filename
>>>> ERROR: cannot check space of 'test1.snap': Inappropriate ioctl for device
>>>> #
>>>>
>>>
>>> tanks for the test case. Now I was able to reproduce the problem. The bug(s) are two:
>>>
>>> 1) to get the treeid of the files/directory, the function lookup_path_rootid() is used, which behaves strangely when it is called on a directory that is BTRFS_EMPTY_SUBVOL_DIR_OBJECTID. In fact this function is commented as following:
>>> [....]
>>> /*
>>>  * For a given:
>>>  * - file or directory return the containing tree root id
>>>  * - subvolume return its own tree id
>>>  * - BTRFS_EMPTY_SUBVOL_DIR_OBJECTID (directory with ino == 2) the result is
>>>  *   undefined and function returns -1
>>>  */
>>> int lookup_path_rootid(int fd, u64 *rootid)
>>> {
>>> [....]
>>>
>>> The caller (du_add_file()) doesn't consider this case.
>>>
>>> 2) in the function du_walk_dir(), an error returned by du_add_file() is ignored, but the return value is not reset. So if the last entry has ino BTRFS_EMPTY_SUBVOL_DIR_OBJECTID (directory with ino == 2) an error is returned. But if there is another directory item no error is returned !
>>>
>>> See the following tests cases:
>>>
>>> # btrfs sub create test1
>>> # btrfs sub create test1/test2
>>> # btrfs sub snap test1 test1.snap
>>> # btrfs fi du -s test1
>>>      Total   Exclusive  Set shared  Filename
>>>      0.00B       0.00B       0.00B  test1
>>> # btrfs fi du -s test1.snap
>>>      Total   Exclusive  Set shared  Filename
>>> ERROR: cannot check space of 'test1.snap': Inappropriate ioctl for device
>>>
>>> But if you add *another* file/dir in test1.snap you got:
>>>
>>> # mkdir test1.snap/dir
>>> # btrfs fi du -s test1.snap
>>>      Total   Exclusive  Set shared  Filename
>>>      0.00B       0.00B       0.00B  test1.snap
>>>
>>> The error disappea> Patches will follow shortly
>>
>> It would be awesome if you manage to introduce xfstests for this case
> 
> I am not sure if this is the right thing to do: the bugs are related to 
> a) an incorrect error handling of the function lookup_path_rootid()
> b) the strange behavior of the BTRFS_EMPTY_SUBVOL_DIR_OBJECTID directory
> 
> For a) it is impossible to check for each lookup_path_rootid() call from a xfstest; for b) I am quite sure that there are a lot of corner case not properly handled in btrfs progs (and still btrfs fi-du handle it wrongly)

So the bug is actually in the btrfsprogs not in the fs, am I correct?

> 
> BR
> G.Baroncelli
> 
>>
>>>
>>>>
>>>> # uname -r
>>>> 4.13.0-0.rc4.git1.1.fc27.x86_64
>>>> # rpm -q btrfs-progs
>>>> btrfs-progs-4.12-1.fc27.x86_64
>>>>
>>>>
>>>> ----
>>>> Chris Murphy
>>>>
>>>
>>>
>> --
>> 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
>>
> 
> 

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: btrfs fi du -s gives Inappropriate ioctl for device
  2017-08-18  7:12           ` Nikolay Borisov
@ 2017-08-18  7:22             ` Goffredo Baroncelli
  0 siblings, 0 replies; 12+ messages in thread
From: Goffredo Baroncelli @ 2017-08-18  7:22 UTC (permalink / raw)
  To: Nikolay Borisov; +Cc: Chris Murphy, Piotr Szymaniak, Btrfs BTRFS

On 08/18/2017 09:12 AM, Nikolay Borisov wrote:
> 
> 
> On 18.08.2017 10:09, Goffredo Baroncelli wrote:
>> On 08/18/2017 08:34 AM, Nikolay Borisov wrote:
[...]
>>> It would be awesome if you manage to introduce xfstests for this case
>>
>> I am not sure if this is the right thing to do: the bugs are related to 
>> a) an incorrect error handling of the function lookup_path_rootid()
>> b) the strange behavior of the BTRFS_EMPTY_SUBVOL_DIR_OBJECTID directory
>>
>> For a) it is impossible to check for each lookup_path_rootid() call from a xfstest; for b) I am quite sure that there are a lot of corner case not properly handled in btrfs progs (and still btrfs fi-du handle it wrongly)
> 
> So the bug is actually in the btrfsprogs not in the fs, am I correct?
> 
Yes, definitively


BR
G.Baroncelli
-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: btrfs fi du -s gives Inappropriate ioctl for device
  2017-08-17 20:59     ` Goffredo Baroncelli
  2017-08-18  6:34       ` Nikolay Borisov
@ 2017-08-18  8:38       ` Piotr Szymaniak
  1 sibling, 0 replies; 12+ messages in thread
From: Piotr Szymaniak @ 2017-08-18  8:38 UTC (permalink / raw)
  To: Goffredo Baroncelli; +Cc: Chris Murphy, Btrfs BTRFS

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

On Thu, Aug 17, 2017 at 10:59:33PM +0200, Goffredo Baroncelli wrote:
> Patches will follow shortly

With your patches applied:

~ # btrfs fi du -s /mnt/red/\@backup/ /mnt/red/\@backup/.snapshot/monthly_2017-08-01_05\:30\:01/ /mnt/red/\@svn/ /mnt/red/\@svn/.snapshot/weekly_2017-08-05_04\:20\:02/
     Total   Exclusive  Set shared  Filename
   1.86TiB    75.73MiB   312.77GiB  /mnt/red/@backup/
 320.29GiB       0.00B   312.19GiB  /mnt/red/@backup/.snapshot/monthly_2017-08-01_05:30:01/
  52.24GiB    10.19MiB     4.13GiB  /mnt/red/@svn/
   4.35GiB     1.05MiB     4.12GiB  /mnt/red/@svn/.snapshot/weekly_2017-08-05_04:20:02/


Best regards,
Piotr Szymaniak.
-- 
Mysle,  ze gdyby  diabel  nie istnial i mialby go stworzyc czlowiek, to
stworzylby go na swoj obraz i podobienstwo.
  -- Fiodor Dostojewski

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2017-08-18  8:38 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-08-14 22:57 btrfs fi du -s gives Inappropriate ioctl for device Piotr Szymaniak
2017-08-14 23:40 ` Chris Murphy
2017-08-16  9:27   ` Piotr Szymaniak
2017-08-17  0:23     ` Chris Murphy
2017-08-17 15:37 ` Goffredo Baroncelli
2017-08-17 18:43   ` Chris Murphy
2017-08-17 20:59     ` Goffredo Baroncelli
2017-08-18  6:34       ` Nikolay Borisov
2017-08-18  7:09         ` Goffredo Baroncelli
2017-08-18  7:12           ` Nikolay Borisov
2017-08-18  7:22             ` Goffredo Baroncelli
2017-08-18  8:38       ` Piotr Szymaniak

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).