[Bug 1174939] New: snapper list on transactional server doesn't show consumed space by snapshots
https://bugzilla.suse.com/show_bug.cgi?id=1174939 Bug ID: 1174939 Summary: snapper list on transactional server doesn't show consumed space by snapshots Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs@suse.de Reporter: william.brown@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- pyrite# snapper list # | Type | Pre # | Date | User | Cleanup | Description | Userdata -----+--------+-------+----------------------------------+------+---------+-------------------------+-------------- 0 | single | | | root | | current | 146 | single | | Thu 30 Jul 2020 01:48:02 AM AEST | root | number | Snapshot Update of #145 | important=yes 147 | single | | Fri 31 Jul 2020 01:40:54 AM AEST | root | number | Snapshot Update of #146 | important=yes 148 | single | | Sat 01 Aug 2020 01:40:03 AM AEST | root | number | Snapshot Update of #147 | important=yes 149 | single | | Sun 02 Aug 2020 01:56:03 AM AEST | root | number | Snapshot Update of #148 | important=yes 150 | single | | Tue 04 Aug 2020 01:16:07 AM AEST | root | number | Snapshot Update of #149 | important=yes 151 | single | | Wed 05 Aug 2020 01:08:46 AM AEST | root | number | Snapshot Update of #150 | important=yes 152 | single | | Wed 05 Aug 2020 06:24:01 PM AEST | root | | Snapshot Update of #151 | 153* | single | | Thu 06 Aug 2020 12:22:00 AM AEST | root | | Snapshot Update of #152 | No size data about snapshots is available, meaning I don't know how much room these are taking up. On transactional server, snapper list should show the consumed size. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174939 https://bugzilla.suse.com/show_bug.cgi?id=1174939#c1 --- Comment #1 from Thorsten Kukuk <kukuk@suse.com> --- Works fine for me: 5 | single | | Tue Aug 4 13:38:05 2020 | root | 130.77 MiB | number | Snapshot Update of #4 | important=yes 6 | single | | Tue Aug 4 16:37:47 2020 | root | 1.20 MiB | number | Snapshot Update of #5 | important=yes 7 | single | | Wed Aug 5 01:34:39 2020 | root | 1.87 MiB | number | Snapshot Update of #6 | important=yes 8 | single | | Wed Aug 5 12:33:16 2020 | root | 3.75 MiB | number | Snapshot Update of #7 | 9 | single | | Wed Aug 5 12:34:09 2020 | root | 3.47 MiB | | Snapshot Update of #7 | 10* | single | | Thu Aug 6 01:03:25 2020 | root | 3.21 MiB | | Snapshot Update of #9 | As you wrote in the other bug report, snapper cannot set the quota for your filesystem. Without quota, it's not possible for snapper to calculate the used size. You should find out why snapper is not able to set the quota on your system. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174939 https://bugzilla.suse.com/show_bug.cgi?id=1174939#c2 --- Comment #2 from William Brown <william.brown@suse.com> --- pyrite# snapper setup-quota Quota error (qgroup already set). pyrite# snapper list # | Type | Pre # | Date | User | Cleanup | Description | Userdata -----+--------+-------+----------------------------------+------+---------+-------------------------+-------------- 0 | single | | | root | | current | ... <snip> It appears quota is "already setup", but snapper list still shows it as missing. dmesg however says: [19066.608743] BTRFS warning (device vda2): qgroup rescan init failed, qgroup is not enabled The btrfs has no cli to display quota status: pyrite# btrfs quota --help usage: btrfs quota <command> [options] <path> btrfs quota enable <path> Enable subvolume quota support for a filesystem. btrfs quota disable <path> Disable subvolume quota support for a filesystem. btrfs quota rescan [-sw] <path> Trash all qgroup numbers and scan the metadata again with the current config. manage filesystem quota settings All of these commands appear to manipulate quota, and due to the layout of subvolumes in transactional server "path" could be a subvol or the filesystem and I'm honestly not sure (which is a usability problem in itself). I am hesitant to start running these commands as I could make the problem worse. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174939 https://bugzilla.suse.com/show_bug.cgi?id=1174939#c3 --- Comment #3 from William Brown <william.brown@suse.com> --- So I gave in and tried this. pyrite# btrfs quota rescan / ERROR: quota rescan failed: Read-only file system [33459.328631] BTRFS warning (device vda2): qgroup rescan init failed, qgroup is not enabled So it looks like it's not able to to be fixed with transactional server unless you take steps like: pyrite# mount -o remount,rw / pyrite# btrfs quota rescan / ERROR: quota rescan failed: Invalid argument [33965.861982] BTRFS info (device vda2): disk space caching is enabled [33967.386755] BTRFS warning (device vda2): qgroup rescan init failed, qgroup is not enabled -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174939 Chenzi Cao <chcao@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|screening-team-bugs@suse.de |aschnell@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174939 https://bugzilla.suse.com/show_bug.cgi?id=1174939#c4 --- Comment #4 from William Brown <william.brown@suse.com> --- I was asked by someone to include my snapper config. This is default from install, and the only snapper config in /etc/snapper/configs/root # cat /etc/snapper/configs/root # subvolume to snapshot SUBVOLUME="/" # filesystem type FSTYPE="btrfs" # btrfs qgroup for space aware cleanup algorithms QGROUP="1/0" # fraction of the filesystems space the snapshots may use SPACE_LIMIT="0.5" # fraction of the filesystems space that should be free FREE_LIMIT="0.2" # users and groups allowed to work with config ALLOW_USERS="" ALLOW_GROUPS="" # sync users and groups from ALLOW_USERS and ALLOW_GROUPS to .snapshots # directory SYNC_ACL="no" # start comparing pre- and post-snapshot in background after creating # post-snapshot BACKGROUND_COMPARISON="yes" # run daily number cleanup NUMBER_CLEANUP="yes" # limit for number cleanup NUMBER_MIN_AGE="1800" NUMBER_LIMIT="2-10" NUMBER_LIMIT_IMPORTANT="4-10" # create hourly snapshots TIMELINE_CREATE="no" # cleanup hourly snapshots after some time TIMELINE_CLEANUP="yes" # limits for timeline cleanup TIMELINE_MIN_AGE="1800" TIMELINE_LIMIT_HOURLY="10" TIMELINE_LIMIT_DAILY="10" TIMELINE_LIMIT_WEEKLY="0" TIMELINE_LIMIT_MONTHLY="10" TIMELINE_LIMIT_YEARLY="10" # cleanup empty pre-post-pairs EMPTY_PRE_POST_CLEANUP="yes" # limits for empty pre-post-pair cleanup EMPTY_PRE_POST_MIN_AGE="1800" -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174939 https://bugzilla.suse.com/show_bug.cgi?id=1174939#c5 Fabian Vogt <fvogt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fvogt@suse.com, | |william.brown@suse.com Flags| |needinfo?(william.brown@sus | |e.com) --- Comment #5 from Fabian Vogt <fvogt@suse.com> --- It's possible that snapper's config has quotas enabled, but the filesystem does not. Does it work if you edit the snapper config to have QGROUP="" and run snapper setup-quota again? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174939 https://bugzilla.suse.com/show_bug.cgi?id=1174939#c6 William Brown <william.brown@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(william.brown@sus | |e.com) | --- Comment #6 from William Brown <william.brown@suse.com> --- The command succeeded after the config change, and it's doing something. pyrite# snapper ls ... dmesg: [21775.924812] BTRFS warning (device vda2): qgroup rescan is already in progress A little while later I finally see: pyrite# snapper ls # | Type | Pre # | Date | User | Used Space | Cleanup | Description | Userdata -----+--------+-------+----------------------------------+------+------------+---------+-------------------------+-------------- 0 | single | | | root | | | current | 157 | single | | Wed 12 Aug 2020 01:47:23 AM AEST | root | 48.63 MiB | number | Snapshot Update of #156 | important=yes 158 | single | | Fri 14 Aug 2020 01:45:56 AM AEST | root | 2.37 MiB | number | Snapshot Update of #157 | important=yes 159 | single | | Sat 15 Aug 2020 12:08:40 AM AEST | root | 14.37 MiB | number | Snapshot Update of #158 | important=yes 160 | single | | Sun 16 Aug 2020 01:49:27 AM AEST | root | 17.46 MiB | number | Snapshot Update of #159 | important=yes 161 | single | | Mon 17 Aug 2020 12:14:32 AM AEST | root | 16.03 MiB | number | Snapshot Update of #160 | important=yes 162 | single | | Tue 18 Aug 2020 01:20:29 AM AEST | root | 9.85 MiB | number | Snapshot Update of #161 | important=yes 163 | single | | Wed 19 Aug 2020 12:24:33 AM AEST | root | 6.18 MiB | | Snapshot Update of #162 | 164* | single | | Fri 21 Aug 2020 12:57:56 AM AEST | root | 57.59 MiB | | Snapshot Update of #163 | I'm curious how my system got into this broken state given it was a very recent fresh install, and I haven't tweaked any of these low level parts, but I guess now that evidence is lost to the sands of time ... -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174939 Arvin Schnell <aschnell@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aschnell@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174939 Arvin Schnell <aschnell@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugzilla.suse.com/s | |how_bug.cgi?id=1174940 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174939 https://bugzilla.suse.com/show_bug.cgi?id=1174939#c7 Arvin Schnell <aschnell@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #7 from Arvin Schnell <aschnell@suse.com> --- I cannot say how the system got into the broken state. AFAIS snapper itself does not disable btrfs quota on the file system level at all. snapper does the modifications like enabling quota on the /.snapshots directory (which is always read-write). Also notice that the read-only flag on btrfs is something different than the read-only flag of the mount command. So a 'mount -o remount,rw /' does not have the desired result. You have to use 'btrfs property get /' to get the read-only flag of the file system. Closing as WORKSFORME. Please reopen if it is known how quotas got disabled. Maybe check kernel messages for errors. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174939 https://bugzilla.suse.com/show_bug.cgi?id=1174939#c8 --- Comment #8 from William Brown <william.brown@suse.com> --- Those kernel messages won't exist, this problem has existed for months and the system rebooted many times. Oh well :( thanks for your help -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174939 https://bugzilla.suse.com/show_bug.cgi?id=1174939#c9 William Brown <william.brown@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME |--- --- Comment #9 from William Brown <william.brown@suse.com> --- Actually, it looks like quota is removed every reboot. So this may be more major than expected. pyrite# snapper ls # | Type | Pre # | Date | User | Cleanup | Description | Userdata -----+--------+-------+----------------------------------+------+---------+-------------------------+-------------- 0 | single | | | root | | current | 157 | single | | Wed 12 Aug 2020 01:47:23 AM AEST | root | number | Snapshot Update of #156 | important=yes 158 | single | | Fri 14 Aug 2020 01:45:56 AM AEST | root | number | Snapshot Update of #157 | important=yes ... // change qgroup="" and rescan and wait ... pyrite# snapper ls # | Type | Pre # | Date | User | Used Space | Cleanup | Description | Userdata -----+--------+-------+----------------------------------+------+------------+---------+-------------------------+-------------- 0 | single | | | root | | | current | 157 | single | | Wed 12 Aug 2020 01:47:23 AM AEST | root | 48.63 MiB | number | Snapshot Update of #156 | important=yes 158 | single | | Fri 14 Aug 2020 01:45:56 AM AEST | root | 2.37 MiB | number | Snapshot Update of #157 | important=yes ... reboot pyrite# snapper ls # | Type | Pre # | Date | User | Cleanup | Description | Userdata -----+--------+-------+----------------------------------+------+---------+-------------------------+-------------- 0 | single | | | root | | current | 157 | single | | Wed 12 Aug 2020 01:47:23 AM AEST | root | number | Snapshot Update of #156 | important=yes 158 | single | | Fri 14 Aug 2020 01:45:56 AM AEST | root | number | Snapshot Update of #157 | important=yes pyrite# dmesg | grep -i btrf [ 3.640945] Btrfs loaded, crc32c=crc32c-intel, assert=on [ 3.642110] BTRFS: device fsid 1fdd971d-49e8-495f-8bbb-e2b50da2b4bb devid 1 transid 312023 /dev/vda2 scanned by systemd-udevd (292) [ 3.712496] BTRFS info (device vda2): disk space caching is enabled [ 3.712500] BTRFS info (device vda2): has skinny extents [ 4.192751] BTRFS info (device vda2): disk space caching is enabled [ 8.799324] BTRFS info (device vda2): disk space caching is enabled [ 12.765641] BTRFS info (device vda2): disk space caching is enabled [ 62.581588] BTRFS warning (device vda2): qgroup rescan init failed, qgroup is not enabled -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174939 https://bugzilla.suse.com/show_bug.cgi?id=1174939#c10 Arvin Schnell <aschnell@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(william.brown@sus | |e.com) --- Comment #10 from Arvin Schnell <aschnell@suse.com> --- Interesting. I want to make clear that snapper is not involved with causing quotas being disabled. You you please run: # btrfs quota enable /.snapshots # btrfs qgroup show / # reboot # btrfs qgroup show / -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174939 https://bugzilla.suse.com/show_bug.cgi?id=1174939#c11 William Brown <william.brown@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(william.brown@sus | |e.com) | --- Comment #11 from William Brown <william.brown@suse.com> --- (In reply to Arvin Schnell from comment #10)
Interesting. I want to make clear that snapper is not involved with causing quotas being disabled. You you please run:
# btrfs quota enable /.snapshots # btrfs qgroup show / # reboot
# btrfs qgroup show /
pyrite# btrfs qgroup show / ERROR: can't list qgroups: quotas not enabled pyrite# btrfs quota enable /.snapshots pyrite# btrfs qgroup show / WARNING: qgroup data inconsistent, rescan recommended qgroupid rfer excl -------- ---- ---- 0/5 0.00B 0.00B 0/256 0.00B 0.00B 0/258 0.00B 0.00B ... 0/1312 0.00B 0.00B 0/1313 0.00B 0.00B pyrite# reboot pyrite# uptime 15:38:14 up 0:00, 1 user, load average: 0.64, 0.18, 0.06 pyrite# btrfs qgroup show / ERROR: can't list qgroups: quotas not enabled -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174939 https://bugzilla.suse.com/show_bug.cgi?id=1174939#c12 Arvin Schnell <aschnell@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Basesystem |Kernel --- Comment #12 from Arvin Schnell <aschnell@suse.com> --- Thanks. I suspect a btrfs problem. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174939 Arvin Schnell <aschnell@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|aschnell@suse.com |kernel-bugs@opensuse.org -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174939 https://bugzilla.suse.com/show_bug.cgi?id=1174939#c13 --- Comment #13 from William Brown <william.brown@suse.com> --- (In reply to Arvin Schnell from comment #12)
Thanks. I suspect a btrfs problem.
So do I :( -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174939 https://bugzilla.suse.com/show_bug.cgi?id=1174939#c14 Takashi Iwai <tiwai@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tiwai@suse.com Assignee|kernel-bugs@opensuse.org |rgoldwyn@suse.com --- Comment #14 from Takashi Iwai <tiwai@suse.com> --- Reassigned to filesystem team. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174939 https://bugzilla.suse.com/show_bug.cgi?id=1174939#c15 Goldwyn Rodrigues <rgoldwyn@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rgoldwyn@suse.com Assignee|rgoldwyn@suse.com |wqu@suse.com Flags| |needinfo?(william.brown@sus | |e.com) --- Comment #15 from Goldwyn Rodrigues <rgoldwyn@suse.com> --- Btrfs doesn't disable quotas on it's own unless a "btrfs quota disable" is issued. Has qgroup scan be allowed to complete with btrfs property ro disabled? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174939 https://bugzilla.suse.com/show_bug.cgi?id=1174939#c16 --- Comment #16 from Wenruo Qu <wqu@suse.com> --- Kernel version please? This looks like a bug in qgroup code where a bad backport is causing the problem. (Preventing qgroup to be enabled at mount time) So exact kernel version would help. And since upstream get it fixed, maybe updating the kernel could also help? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174939 https://bugzilla.suse.com/show_bug.cgi?id=1174939#c17 William Brown <william.brown@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(william.brown@sus | |e.com) | --- Comment #17 from William Brown <william.brown@suse.com> ---
So exact kernel version would help.
kernel-default-5.8.0-1.1.x86_64
And since upstream get it fixed, maybe updating the kernel could also help?
This is transactional tumbleweed, and it's automatically updating/rebooting. There are no further updates available to the system at this time. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174939 https://bugzilla.suse.com/show_bug.cgi?id=1174939#c18 Wenruo Qu <wqu@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(william.brown@sus | |e.com) --- Comment #18 from Wenruo Qu <wqu@suse.com> --- Would you please try the following workload? # btrfs quota disable <mnt> # btrfs ins dump-tree -t quota <device> # btrfs quota en <mnt> # btrfs ins dump-tree -t quota <device> # reboot # btrfs qgroup show -prce <mnt> Along with the dmesg (from quota disable to next mount). BTW, how can I get the kernel-source commit for the v5.8.0-1 kernel? The stable/upstream kernel doesn't have rpm-* tag, and the current stable is already v5.8.3, thus I can't get the exact source to verify if it's a fixed bug. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174939 https://bugzilla.suse.com/show_bug.cgi?id=1174939#c19 William Brown <william.brown@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(william.brown@sus | |e.com) | --- Comment #19 from William Brown <william.brown@suse.com> --- Created attachment 841047 --> https://bugzilla.suse.com/attachment.cgi?id=841047&action=edit Tar of dmesg before/after reboot, and command outputs. These are the outputs as requested. I'm not sure about the kernel sources, this is up to date tumbleweed so I guess they would be in build.opensuse.org? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174939 https://bugzilla.suse.com/show_bug.cgi?id=1174939#c20 --- Comment #20 from Fabian Vogt <fvogt@suse.com> --- (In reply to Wenruo Qu from comment #18)
BTW, how can I get the kernel-source commit for the v5.8.0-1 kernel? The stable/upstream kernel doesn't have rpm-* tag, and the current stable is already v5.8.3, thus I can't get the exact source to verify if it's a fixed bug.
The description of that package says: Source Timestamp: 2020-08-04 07:30:59 +0000 GIT Revision: 9bc0044f23a1ebc1496c9ed8967e0aa5d0a5685e GIT Branch: stable -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174939 https://bugzilla.suse.com/show_bug.cgi?id=1174939#c21 --- Comment #21 from Wenruo Qu <wqu@suse.com> --- Got the same kernel version from kernel-source, but still failed to reproduce on newly created fs. Thus I guess there is something related to the fs. Would you please take a btrfs-image dump by: # btrfs-image -c9 <device> dump.img This need the fs to be unmounted. And upload to the R&D network server. Feel free to do extra compression on the image dump. And since the fs needs to be unmounted anyway, a btrfs check may also help. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174939 https://bugzilla.suse.com/show_bug.cgi?id=1174939#c22 --- Comment #22 from William Brown <william.brown@suse.com> --- Created attachment 841094 --> https://bugzilla.suse.com/attachment.cgi?id=841094&action=edit Screenshot of btrfs check
Would you please take a btrfs-image dump by:
# btrfs-image -c9 <device> dump.img
Done.
This need the fs to be unmounted. And upload to the R&D network server.
I don't know where this server is or how to access it. Can you tell me more about it so I can do this upload?
And since the fs needs to be unmounted anyway, a btrfs check may also help.
Screenshot attached. No errors were found. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174939 https://bugzilla.suse.com/show_bug.cgi?id=1174939#c23 --- Comment #23 from Wenruo Qu <wqu@suse.com> --- (In reply to William Brown from comment #22)
Created attachment 841094 [details] Screenshot of btrfs check
Would you please take a btrfs-image dump by:
# btrfs-image -c9 <device> dump.img
Done.
This need the fs to be unmounted. And upload to the R&D network server.
I don't know where this server is or how to access it. Can you tell me more about it so I can do this upload?
If it's not too big (<5G), then I guess you can upload to public file host of your taste. Things like Google driver maybe fine?
And since the fs needs to be unmounted anyway, a btrfs check may also help.
Screenshot attached. No errors were found.
-- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174939 https://bugzilla.suse.com/show_bug.cgi?id=1174939#c26 --- Comment #26 from Wenruo Qu <wqu@suse.com> --- Also surprisingly, even with that 5.8.0-default kernel compiled from commit 9bc0044f23a1ebc1496c9ed8967e0aa5d0a5685e, the kernel mount the dumpped fs without any problem, and qgroup rescan also works perfectly. This means the on-disk data of the fs is completely fine. So it must be some runtime problem. I guess a reboot, and then try "btrfs quota enable" still doesn't work right? BTW, could it be related to btrfs-progs? What's the version of btrfs-progs? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174939 https://bugzilla.suse.com/show_bug.cgi?id=1174939#c27 --- Comment #27 from William Brown <william.brown@suse.com> --- # rpm -qa | grep -i btrfs btrfsprogs-5.7-1.3.x86_64 btrfsprogs-udev-rules-5.7-1.3.noarch libbd_btrfs2-2.22-3.4.x86_64 libbtrfs0-5.7-1.3.x86_64 btrfsmaintenance-0.4.2-3.3.noarch libudisks2-0_btrfs-2.8.4-1.3.x86_64 Remember, it's that every reboot the quota details are getting lost. The enable and rescan works, but something is causing that data to be lost during reboots. :( -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com