Re: Subvolume creation returns file exists

[Hugo Mills <hugo@carfax.org.uk>]

[-- Attachment #1: Type: text/plain, Size: 2665 bytes --]

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!"            

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]