Re: Subvolume creation returns file exists

[Duncan <1i5t5.duncan@cox.net>]

Alin Dobre posted on Fri, 15 Nov 2013 14:33:58 +0000 as excerpted:

> 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

I'd suggest staying away from quotas on btrfs at this point.  There's 
something going on there that just doesn't work correctly, and a lot of 
folks have been reporting quota-related bugs.  So if your use-case needs 
quotes, try a different filesystem.  If it doesn't, consider disabling 
them for the time being (and reboot, since apparently some bits don't 
fully disable until after a reboot).

You can read the list for more detail.  AFAIK there's some very recent 
patches that address at least part of the problem, but they're recent 
enough I don't believe they're in 3.12, and the 3.13 commit-window pull 
was just requested in the last 24 hours or so, so they're likely not even 
in 3.13 yet.  Even then, however, I'd test for awhile before relying on 
btrfs quotas, because I'm not sure if the new patches fix all the bugs or 
simply fix enough for the next batch to make their appearance.

Meanwhile, it's worth noting what both the btrfs kernel option and the 
wiki[1] say about btrfs state: btrfs is still an experimental 
filesystem.  Don't use it with data you can't afford to lose (either make 
and test your backups to the point that you're comfortable with the 
possibility of full btrfs loss should the worst occur, or use only 
scratch data you don't care about losing in the first place), and DO keep 
updated, as btrfs development is quite rapid and every kernel includes 
fixes for known problems, some of which don't get ported back to stable-
series kernels.  If you're running 3.8, that means you're missing the 
fixes in 3.9-3.12, four full release kernel series!

There are reasons one may wish to run an older kernel, but in general 
they're not compatible with the reasons one might have for running an 
experimental filesystem such as btrfs.  Therefore, if you're going to 
test btrfs, please try to run a current release kernel, now 3.12, if not 
the development kernel, now 3.13. (FWIW, while I personally do run 
development kernels, I prefer not to switch to them until rc2 or so, at 
which point hopefully the worst data-risk bugs will be addressed.)  If 
you prefer to be more conservative and run older, more tested kernels, 
it's quite likely that the still experimental btrfs doesn't fit your use-
case very well either, and you should probably be using something 
considered more stable.

The same applies, tho to a bit lessor degree, to btrfs-progs. 0.19 is 
OLD.  Even 0.20-rc1, the latest rc, is about a year old!  Btrfs-progs 
development happens in branches that are only integrated to master once 
they're considered stable enough for release.  As a result and due to 
continued development, a build from a recent btrfs-progs git-master pull 
is always going to be the most stable and ideal testing version you can 
run.

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 I don't know whether it's in master yet).

Btrfs v0.20-rc1-591-gc652e4e

[1] https://btrfs.wiki.kernel.org

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