* Negative qgroup sizes
@ 2014-05-01 13:32 Alin Dobre
2014-05-01 16:58 ` Duncan
0 siblings, 1 reply; 3+ messages in thread
From: Alin Dobre @ 2014-05-01 13:32 UTC (permalink / raw)
To: linux-btrfs
Hello,
I am having trouble with one of the btrfs subvolumes, as it shows
negative quota accounting values, like in the following output:
# btrfs qgroup show -f /tmp/test
qgroupid rfer excl
-------- ---- ----
0/299 -1576960 -1511424
Running a "btrfs quota rescan -w /tmp/test" seems to fix it, but it
seems to come back pretty often (happened twice in the last couple of
days). I can't think of a possible reproduction of the problem, so I'm
just stuck. Here's the output of subvolume after the rescan, maybe it
also gives you some insight:
# btrfs qgroup show -f /tmp/test
qgroupid rfer excl
-------- ---- ----
0/299 1065955328 1056542720
The kernel we are using is 3.14.1 (stable) and the btrfs-progs version
is 3.12.
Any idea on why this happens or if there's an obvious fix I missed?
Cheers,
Alin.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Negative qgroup sizes
2014-05-01 13:32 Negative qgroup sizes Alin Dobre
@ 2014-05-01 16:58 ` Duncan
2014-05-02 9:17 ` Alin Dobre
0 siblings, 1 reply; 3+ messages in thread
From: Duncan @ 2014-05-01 16:58 UTC (permalink / raw)
To: linux-btrfs
Alin Dobre posted on Thu, 01 May 2014 14:32:55 +0100 as excerpted:
> I am having trouble with one of the btrfs subvolumes, as it shows
> negative quota accounting values
> Running a "btrfs quota rescan -w /tmp/test" seems to fix it, but it
> seems to come back pretty often (happened twice in the last couple of
> days).
> The kernel we are using is 3.14.1 (stable) and the btrfs-progs version
> is 3.12.
I'm not a qgroups user myself, but I know there were quite some
complaints about negative numbers some months ago. I hadn't seen any in
awhile and had hoped the problems were all fixed, but now you're
reporting them again, so I guess not.
Tho you are slightly outdated on your btrfs-progs version, 3.14.1 being
current. But I think the code in question is kernel code and the progs
simply report it, so I don't think that can be the problem in this case.
The earlier recommendation, back when the problem reports were common,
was not to use qgroups on btrfs as the code obviously wasn't accounting
for something correctly. Either use btrfs without qgroups, or if you
really need quotas, use some other filesystem where the quota code works
reliably.
As for the problems themselves, I saw some patches go by that fixed
qgroups issues related to snapshot maintenance, and it's possible there's
more work to do in that area. The problem there is apparently due to the
difficulty in properly accounting quotas for shared data, such that
deleting old snapshots could turn things negative as the code subtracted
the quota numbers repeatedly, once for each snapshot deleted, instead of
properly figuring out what was shared and only subtracting for the data
unique to that snapshot when it was deleted.
So if you are doing snapshots, you can try not doing them (switching to
conventional backup if necessary) and see if that stabilizes your
numbers. If so, you know there's still more problems in that area.
Of course if the subvolumes involved aren't snapshotted, then the problem
must be elsewhere, but I do know the snapshotting case /is/ reasonably
difficult to get right... while staying within a reasonable performance
envelope at least.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Negative qgroup sizes
2014-05-01 16:58 ` Duncan
@ 2014-05-02 9:17 ` Alin Dobre
0 siblings, 0 replies; 3+ messages in thread
From: Alin Dobre @ 2014-05-02 9:17 UTC (permalink / raw)
To: Duncan, linux-btrfs
Thanks for the response, Duncan.
On 01/05/14 17:58, Duncan wrote:
>
> Tho you are slightly outdated on your btrfs-progs version, 3.14.1 being
> current. But I think the code in question is kernel code and the progs
> simply report it, so I don't think that can be the problem in this case.
Yes, I'm aware that 3.14 version of btrfs progs was already there, but
this is just for couple of weeks and I'm pretty sure that the kernel
code (which does the real time accounting) is broken.
> So if you are doing snapshots, you can try not doing them (switching to
> conventional backup if necessary) and see if that stabilizes your
> numbers. If so, you know there's still more problems in that area.
>
> Of course if the subvolumes involved aren't snapshotted, then the problem
> must be elsewhere, but I do know the snapshotting case /is/ reasonably
> difficult to get right... while staying within a reasonable performance
> envelope at least.
>
I have already searched and found some patches around this issue, but I
thought I'd also mention the issue on this mailing list and hoped that I
somehow missed something. The subvolumes are highly probable to be
snapshotted, so this might indeed be the case.
Cheers,
Alin.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-05-02 9:17 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-01 13:32 Negative qgroup sizes Alin Dobre
2014-05-01 16:58 ` Duncan
2014-05-02 9:17 ` Alin Dobre
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.