It seems that the problem was that we didn't delete the corresponding
qgroup when deleting the subvolume, which was filling the metadata with
unused information. Removing all the stale qgroups fixes the problem and
allows subsequent subvolume creation without any quota disable/enable
action.
Hi Alin,
On 11/28/2013 06:01 PM, Alin Dobre wrote:
It seems that the problem was that we didn't delete the corresponding
qgroup when deleting the subvolume, which was filling the metadata
with unused information. Removing all the stale qgroups fixes the
problem and allows subsequent subvolume
Duncan posted on Fri, 15 Nov 2013 16:07:22 + as excerpted:
FWIW, here's the version string from my btrfs-progs, updated a couple
days ago (tho there's one known bug in it, related to doing a mkfs.btrfs
on a sub-GiB filesystem, patch posted to list but as I've not updated in
a couple days
Hello,
We are using btrfs filesystems in our infrastructure and, at some point
of time, they start refusing to create new subvolumes.
Each file system is being quota initialized immediately after its
creation (with btrfs quota enable) and then all subfolders under the
root directory are
On Fri, Nov 15, 2013 at 02:33:58PM +, Alin Dobre wrote:
We are using btrfs filesystems in our infrastructure and, at some
point of time, they start refusing to create new subvolumes.
Each file system is being quota initialized immediately after its
creation (with btrfs quota enable) and
On Fri, Nov 15, 2013 at 9:27 AM, Hugo Mills h...@carfax.org.uk wrote:
On Fri, Nov 15, 2013 at 02:33:58PM +, Alin Dobre wrote:
We are using btrfs filesystems in our infrastructure and, at some
point of time, they start refusing to create new subvolumes.
Each file system is being quota
