Anand Patil posted on Wed, 25 Mar 2015 16:45:09 -0700 as excerpted: > I have a BTRFS filesystem on a 1TB block device, kernel 3.16.2+, tools > v3.14_pre20140414. There are many (several thousand) subvolumes, folders > and small files.
Sean G answered your immediate question (no, about full metadata doesn't mean you're about out of space as long as there's still unallocated space left to allocate more metadata chunks from), and he's correct, but the bit I quoted above is a potential warning flag of a different nature... But, that last sentence of the quote can be parsed at least two different ways. Did the "several thousand" refer to subvolumes AND folders AND files, or only to subvolumes? The concern here is that btrfs doesn't scale particularly well to thousands of /subvolumes/, and while normal usage shouldn't suffer much, btrfs management commands such as btrfs balance and btrfs check, can take MUCH longer than they should, with that many subvolumes. The question of number of subvolumes normally occurs in the context of snapshots, since snapshots are a special kind of subvolume. Ideally, you'll want to keep the total number of subvolumes (including snapshots) to under 1000, with the number of snapshots of any single subvolume limited to 250-ish (say under 300). However, even just four subvolumes being snapshotted to this level will reach the thousand, and 2000-3000 total isn't /too/ bad as long as it's no more than 250-300 snapshots per subvolume. But DEFINITELY try to keep it under 3000, and preferably under 2000, as the scaling really does start to go badly as the number of subvolumes increases beyond that. If you're dealing with 10k subvolumes/ snapshots, that's too many and you ARE likely to find yourself with problems. (With something like snapper, configuring it for say half-hour or hourly snapshots at the shortest time, with twice-daily or daily being more reasonable in many circumstances, and then thinning it down to say daily after a few days and weekly after four weeks, goes quite a long way toward reducing the number of snapshots per subvolume. Keeping it near 250-ish per subvolume is WELL within reason, and considering that a month or a year out, you're not likely to /care/ whether it's this hour or that, just pick a day or a week and if it's not what you want, go back or forward a day or a week, is actually likely to be more practical than having hundreds of half-hourly snapshots a year old to choose from. And 250-ish snapshots per subvolume really does turn out to be VERY reasonable, provided you're doing reasonable thinning.) So you can see where "several thousand" subvolumes raised red flags for me, even if it's also possible to parse it as only a handful of subvolumes, with the rest of the several thousand being directories and files. Meanwhile, it's also worth considering your kernel and userspace versions. Kernel 3.16 is a bit behind now, tho not /too/ bad, but I'd consider updating to 3.18 or 3.19 pretty soon. Your userspace, however, is much further behind at 3.14. Generally, it goes like this. During normal runtime, the kernel is most critical as userspace simply relays commands to the kernel and it's the kernel code doing the work. However, if something goes wrong and you're running for example btrfs check and/or btrfs restore to try to recover your data, THAT is when userspace code goes to work and a current userspace with as many of the previous bugs as possible patched, can mean the difference between an easy and mostly uneventful recovery and unnecessarily losing everything due to a bug fixed in the last version or two. So you definitely want a current btrfs-progs userspace (now 3.19.1 I believe, I'm a couple weeks old myself and still have a 3.19-rc) if you end up trying to recover, and given that, you might as well be running it routinely, as well. And you definitely want a pretty current kernel as well, tho hanging one back (to 3.18 now, since 3.19 is current and 4.0 aka 3.20 is in development) and paying attention to the list to see if there's any unfixed bugs in the new version before updating has proven useful with a couple kernels, recently. Which means your 3.16 kernel is a bit dated, and your 3.14-pre userspace is QUITE dated. You really should consider updating, at least your userspace, before you find you need it for recovery. And the kernel too, as soon as convenient, tho that's less critical for the moment as while moderately outdated, it's a couple kernel/userspace development cycles newer newer than your userspace. -- 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 -- 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
