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. > > Next are some facts about this. Since we found that it's the ioctl > call which returns EEXIST, the place to further track the problem > down was into the kernel module, which assumes that the userspace > tools are not generating the problem. Here is a high level traceback > of the problem: > ioctl.c:create_subvol() returns -EEXIST > cgroup.c:btrfs_qgroup_inherit() returns -EEXIST > qgroup.c:add_qgroup_item() returns -EEXIST > ctree.c:btrfs_insert_empty_item() returns -EEXIST > ctree.c:btrfs_search_slot() returns 0 > ctree.c:key_search() returns 0 > > The problem appeared before our current kernel, which is a 3.8 > version (along with Btrfs progs v0.19), however mounting an already > broken filesystem in a 3.12 kernel (with Btrfs progs > v0.20-rc1-358-g194aa4a) doesn't do any better. > > Any thoughts on this? We can provide you with more information, if > needed, even the broken filesystem itself. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- "What are we going to do tonight?" "The same thing we do --- every night, Pinky. Try to take over the world!"
signature.asc
Description: Digital signature
