Karsai, Gabor posted on Sat, 06 Jan 2018 01:34:09 + as excerpted:
> I created a subvolume on a btrfs, set a limit and the quota is enforced
> - dumping too much data into the subvolume results in a 'quota exceeded'
> message (from dd, for example). But when I am trying to get netlink
> socket notifications, nothing arrives on the socket (I am using pyroute2
> which is supposedly able to receive disk quota notifications)
>
> $ uname -a
> Linux riaps-dev 4.10.0-42-generic #46~16.04.1-Ubuntu SMP
> Mon Dec 4 15:57:59 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
>
> btrfs: whatever Ubuntu 16.04 has
>
> Kconfig:
> CONFIG_QUOTA_NETLINK_INTERFACE=y
Someone with a bit more knowledge of quotas in general and btrfs quotas
in particular will hopefully confirm (I'm just a btrfs user and list
regular, without quotas in my own use-case, so this is only what I've
seen on-list), but sometimes a fast non-authoritative answer can be more
useful than a slower authoritative answer, so here's the first...
Btrfs quotas don't use the normal kernel quota mechanism as they work
somewhat differently. Indeed, the kernel-config help for CONFIG_QUOTA
doesn't mention btrfs support at all. As such, I don't believe the btrfs
quota subsystem uses the normal kernel quota netlink interface at all.
At least, I've never seen it mentioned, and it would surprise me if btrfs
quotas /did/ use that interface, because they are different enough to be
unlikely to properly match the expected interface API.
Meanwhile, be aware that until recently btrfs quotas were too buggy to be
used reliably. While they work rather better now, more minor fixes are
still being made, with every recent kernel including 4.14 having quota
fixes. For this feature a current kernel is definitely recommended, and
4.10 is neither an LTS kernel series (4.9 and 4.14 are the two most
recent and best supported LTS series, 4.10 was simply a normal kernel and
only had upstream support thru 4.11) nor within the latest two current
kernels, so on-list support won't be as good as if you were running an LTS
or current kernel.
And even with the fixes, enabling quotas increases btrfs scaling issues
when running commands such as btrfs balance and check, tho normal runtime
performance isn't so severely affected. Balance in particular takes /
much/ longer when quotas are enabled due to constant quota updates as the
blockgroups are moved around, so temporarily disabling them during
balances is recommended to speed up the balance. Unfortunately, the
scenarios under which you're likely to need to run check, when the
filesystem won't mount, prevent disabling quotas then.
So while quota numbers should be reliable with supported kernels now,
leaving them off unless you really need the feature is still recommended.
The one good thing for use-cases that /do/ need quotas is that such use-
cases tend to be commercial systems with proper backups, where the
performance of commands such as balance and check may not matter so much,
since maintenance in such use-cases often consists of failing the entire
filesystem and falling back to the hot-spare, rather than trying to do on-
the-fly filesystem maintenance such as rebalancing to a new device or
raid layout or checking and trying to repair a filesystem that won't
mount. Since normal runtime performance isn't particularly affected,
quotas tend to be fine for such use-cases.
--
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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
