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 +0000, 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 then all subfolders under >> the root directory are created as subvolumes (btrfs subvolume >> create). Over time, these subvolumes may also be deleted. What's >> under subvolumes are just various files and directories, should not >> be related to this problem. >> >> After a while of using this setup, without any obvious steps to >> reproduce it, the filesystem goes into a state where the following >> happens: >> # btrfs subvolume create btrfs_mount/test_subvolume >> Create subvolume 'btrfs_mount/test_subvolume' >> ERROR: cannot create subvolume - File exists > > We've had someone else with this kind of symptom (snapshot/subvol > creation fails unexpectedly) on IRC recently. I don't think they've > got to the bottom of it yet, but the investigation is ongoing. I've > cc'd Carey in on this, because he was the one trying to debug it. > > Hugo. > >> In regards to data, the filesystem is pretty empty, it only has a >> single empty directory. I don't know about the metadata, at this >> point. >> >> The problem goes away if we disable and re-enable the quota. It all >> seems to be some dead metadata lying around.
And indeed, it turns out I did have quotas enabled, and disabling them restores the ability to create subvolumes. -- 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
