Btrfs check error

Hello! I want to shrink my btrfs Garuda partition using Gparted on a live cd, but the "btrfs check" command Gparted runs before applying any operations, fails with the following message:

Opening filesystem to check...
Checking filesystem on /dev/nvme0n1p5
UUID: 1e6dced2-7257-4b09-bc7a-ff320fb0b1ed
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups
Counts for qgroup id: 0/332 are different
our:		referenced 8713555968 referenced compressed 8713555968
disk:		referenced 8713555968 referenced compressed 8713555968
our:		exclusive 1176907776 exclusive compressed 1176907776
disk:		exclusive 1148502016 exclusive compressed 1148502016
diff:		exclusive 28405760 exclusive compressed 28405760
found 16871546880 bytes used, error(s) found
total csum bytes: 15483652
total tree bytes: 658964480
total fs tree bytes: 606420992
total extent tree bytes: 31948800
btree space waste bytes: 110815280
file data blocks allocated: 19913306112
 referenced 27457921024

Everything seems fine while using Garuda though, and the installation is only a month old. Could the zstd compression have anything to do with it? Has anyone experienced a similar issue? Should I proceed executing "btfs check --repair"? Thanks in advance!

PS: according to this conversation, it seems like the error is not important (why return 1 then?).

What error? I donā€™t see any error.
If you watch and notice the numbers, they say all is fine.

You should check the manual for the definition of error codes and their real meaning. What does it say?

1 Like

Well, I quote ā€œfound 16871546880 bytes used, error(s) foundā€. Also, from the btrfs-check man page: ā€œbtrfs check returns a zero exit status if it succeeds. Non zero is returned in case of failure.ā€. I canā€™t seem to be able to find any more info about btrfs-check or look at the source.

PS: Ī•Ļ…Ļ‡Ī±ĻĪ¹ĻƒĻ„ĻŽ :wink: (thank you in Greek)

1 Like

Zero out of 332 are different

They are the same, I suppose there is noone missing??

Also found how many are used, and <empty> errors found.

I donā€™t know what the dev means, but it seems it may be a UI mistake/bug??

Disclaimer: I donā€™t use this utility, so I only observe the output :man_shrugging:

1 Like

Good catch! Thatā€™s probably worth mentioning to the btrfs devs. Also, I cloned the partition (cause I was scared of running --repair on my daily driver), and after the ā€œā€“repairā€, 0 was returned and no error(s) were reported, with no apparent loss of data (again, it was tested on a cloned partition).

Edit: After a bit of chatting on the btrfs IRC channel, the output seems correct; the error is reported by the line ā€œdiff: exclusive 28405760 exclusive compressed 28405760ā€. ā€œ0/332ā€ does not mean ā€œ0 out of 332ā€, but it is rather an id for a quota group that corresponds to a subvolume. Fun fact, they called me brave for having quotas enabled, which is Garudaā€™s default I think (since I havenā€™t changed anything). So perhaps, you should reconsider having them enabled by default.

Edit #2: Disabling and re-enabling quotas using:

sudo btrfs quota disable / 
sudo btrfs quota enable / 

seems to also solve the error I was getting. Definitely worth trying before using ā€œā€“repairā€.

3 Likes

Arenā€™t quotas enabled by default on BTRFS? Hmmā€¦ :thinking:

Apparently not:

It kind of sounds like Timeshift is wrong to ā€œrecommendā€ qgroups being enabledā€¦

image

4 Likes

There is an opened issue in Timeshift's GitHub repo regarding this:

But till now I didn't have any such issue like deleting snapshot takes hours, maybe because I didn't have too many snapshots :man_shrugging:

I also noticed that Timeshift deletes some autosnap snapshots while taking new autosnap, by default, preventing too many snapshots. So due to this setup, we are not prone to this bug and don't need to worry :wink:

Can anyone help me understand what are quotas and why do we actually need them? So far it seems to me they only cause issues.

I picked up just some reading...
General concept
https://wiki.archlinux.org/title/Disk_quota
Btrfs concept
https://btrfs.wiki.kernel.org/index.php/Quota_support

3 Likes

Should've guessed the arch wiki had a better explanation than the btrfs wiki :grinning_face_with_smiling_eyes:. So quotas in a single-user OS serve little purpose, am I right?

1 Like

I don't know.
It makes sense in general.
Maybe someone knows better :blush:
For sure I remember several posts complaining or solving problems disabling quotas.
But I think quotas make more sense considering timeshift...

Indeed. Timeshift doesn't show the size of btrfs snapshots unless quotas are enabled.

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.