Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Andrei Borzenkov <arvidjaar@gmail.com>
To: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Confused by btrfs quota group accounting
Date: Sat, 22 Jun 2019 18:11:52 +0300	[thread overview]
Message-ID: <eeb418d8-13a1-39c3-c6d1-dd5a2127abc9@gmail.com> (raw)

Linux 10.0.2.15 5.1.7-1-default #1 SMP Tue Jun 4 07:56:54 UTC 2019
(55f2451) x86_64 x86_64 x86_64 GNU/Linux

Consider the following:

10:~ # mkfs.btrfs -f /dev/vdb /dev/vdc
btrfs-progs v5.1
See http://btrfs.wiki.kernel.org for more information.

Label:              (null)
UUID:               d10df0fa-25aa-4d80-89d9-16033ae3392d
Node size:          16384
Sector size:        4096
Filesystem size:    2.00GiB
Block group profiles:
  Data:             RAID0           204.75MiB
  Metadata:         RAID1           102.38MiB
  System:           RAID1             8.00MiB
SSD detected:       no
Incompat features:  extref, skinny-metadata
Number of devices:  2
Devices:
   ID        SIZE  PATH
    1     1.00GiB  /dev/vdb
    2     1.00GiB  /dev/vdc

10:~ # mount /dev/vdb /mnt
10:~ # cd -
/mnt
10:/mnt # btrfs quota enable .
10:/mnt # btrfs sub cre test
Create subvolume './test'
10:/mnt # dd if=/dev/urandom of=test/file bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 6.71373 s, 160 MB/s
10:/mnt # sync
10:/mnt # btrfs qgroup show .
qgroupid         rfer         excl
--------         ----         ----
0/5          16.00KiB     16.00KiB
0/258         1.00GiB      1.00GiB
10:/mnt # filefrag -v test/file
Filesystem type is: 9123683e
File size of test/file is 1073741824 (262144 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..   43135:      33664..     76799:  43136:
   1:    43136..   97279:      86048..    140191:  54144:      76800:
   2:    97280..  151551:     143392..    197663:  54272:     140192:
   3:   151552..  207359:     200736..    256543:  55808:     197664:
   4:   207360..  262143:     258080..    312863:  54784:     256544:
last,eof
test/file: 5 extents found


OK, we have 1Gib file consisting of 5 extents ~200MiB each, btrfs quota
reports 1GiB exclusive in subvolume test which is correct.

10:/mnt # btrfs subvolume snapshot -r test snap1
Create a readonly snapshot of 'test' in './snap1'
10:/mnt # sync
10:/mnt # btrfs qgroup show .
qgroupid         rfer         excl
--------         ----         ----
0/5          16.00KiB     16.00KiB
0/258         1.00GiB     16.00KiB
0/263         1.00GiB     16.00KiB
10:/mnt # filefrag -v test/file
Filesystem type is: 9123683e
File size of test/file is 1073741824 (262144 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..   43135:      33664..     76799:  43136:             shared
   1:    43136..   97279:      86048..    140191:  54144:      76800: shared
   2:    97280..  151551:     143392..    197663:  54272:     140192: shared
   3:   151552..  207359:     200736..    256543:  55808:     197664: shared
   4:   207360..  262143:     258080..    312863:  54784:     256544:
last,shared,eof
test/file: 5 extents found

Also correct, content of test and snap1 is shared so we have two
subvolumes with zero exclusive usage. Also good.

10:/mnt # dd if=/dev/urandom of=test/file bs=1M count=100 seek=0
conv=notrunc
100+0 records in
100+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 0.685532 s, 153 MB/s
10:/mnt # sync
10:/mnt # btrfs qgroup show .
qgroupid         rfer         excl
--------         ----         ----
0/5          16.00KiB     16.00KiB
0/258         1.01GiB    100.02MiB
0/263         1.00GiB     85.02MiB
10:/mnt # filefrag -v test/file
Filesystem type is: 9123683e
File size of test/file is 1073741824 (262144 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..   22463:     315424..    337887:  22464:
   1:    22464..   25599:      76896..     80031:   3136:     337888:
   2:    25600..   43135:      59264..     76799:  17536:      80032: shared
   3:    43136..   97279:      86048..    140191:  54144:      76800: shared
   4:    97280..  151551:     143392..    197663:  54272:     140192: shared
   5:   151552..  207359:     200736..    256543:  55808:     197664: shared
   6:   207360..  262143:     258080..    312863:  54784:     256544:
last,shared,eof
test/file: 7 extents found
10:/mnt # filefrag -v snap1/file
Filesystem type is: 9123683e
File size of snap1/file is 1073741824 (262144 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..   43135:      33664..     76799:  43136:
   1:    43136..   97279:      86048..    140191:  54144:      76800: shared
   2:    97280..  151551:     143392..    197663:  54272:     140192: shared
   3:   151552..  207359:     200736..    256543:  55808:     197664: shared
   4:   207360..  262143:     258080..    312863:  54784:     256544:
last,shared,eof
snap1/file: 5 extents found


Oops. Where 85MiB exclusive usage in snapshot comes from? I would expect
one of

- 0 exclusive, because original first extent is still referenced by test
(even though partially), so if qgroup counts physical space usage, snap1
effectively refers to the same physical extents as test.

- 100MiB exclusive if qgroup counts logical space consumption, because
snapshot now has 100MiB different data.

But 85MiB? It does not match any observed value. Judging by 1.01GiB of
referenced space for subvolume test, qrgoup counts physical usage, at
which point snapshot exclusive space consumption remains 0.

             reply	other threads:[~2019-06-22 15:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-22 15:11 Andrei Borzenkov [this message]
2019-06-23  7:55 ` Confused by btrfs quota group accounting Qu Wenruo
2019-06-23  8:08   ` Qu Wenruo
2019-06-23 10:15     ` Andrei Borzenkov
2019-06-23 11:29       ` Qu Wenruo
2019-06-23 13:42         ` Andrei Borzenkov
2019-06-23 13:55           ` Qu Wenruo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eeb418d8-13a1-39c3-c6d1-dd5a2127abc9@gmail.com \
    --to=arvidjaar@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox