From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: usrquota
Date: Fri, 17 Jan 2014 18:24:26 +0000 (UTC) [thread overview]
Message-ID: <pan$195b9$80426a01$8783bbd1$4f640ee9@cox.net> (raw)
In-Reply-To: 20140117141841.GA2838@rz.uni-freiburg.de
Martin Walter posted on Fri, 17 Jan 2014 15:18:41 +0100 as excerpted:
> Our problem is a zfs with 20,000 quota-enabled homedirectories and 100
> snapshots.
> We would really like to do the same with btrfs, but we don't know how to
> replace the zfs quotas with btrfs subvolume quotas. It seems unfeasible
> to handle 2,000,000 subvolumes.
> e.g. we would have to create every hour 20,000 snapshots and delete the
> same amount.
>
> Is there any chance to get real user quotas with btrfs?
At present I'd suggest staying away from quotas on btrfs in any case, as
there have been some serious bugs (quotas going negative with snapshot
deletion, etc) in the way they're tracked. I don't use quotas here so
haven't closely followed status and perhaps the bugs are fixed, but never-
the-less, it's something I'd recommend staying away from for the time
being. Certainly for usage at that scale. I'd suggest reexamining that
decision perhaps a year from now, but it's simply not ready for that, now.
So I'd say stick with zfs for quota usage at that scale, for now.
On a more general note, btrfs is just beginning to stabilize in
general... the kernel config warnings were just toned down for 3.13,
etc. However, as mkfs.btrfs warns when you create a btrfs filesystem,
it's still not entirely stable. This year should bring a lot of
stabilization as development focus gradually switches from features to
stabilization, but again, for production deployment at that scale, I'd
suggest waiting a year and reexamining the question.
Of course you can still do pilot deployments now, but even more than with
fully stable filesystems, be sure you have current and tested backups,
because it's still possible you'll need to use them. Also, using the
current latest stable kernel (so 3.12.x currently, soon to be 3.13) if
not the development kernel is still recommended, as critical fixes still
go into every new kernel, and while they're marking more of them for
stable now, not all of them reach stable. Again, the warning was only
toned down with 3.13, so from there I'd hope they backport stable fixes,
but I wouldn't count on it before that. And btrfs-tools, while less
critical, is kernel-version synced from 3.12 as well, so you want a btrfs-
tools release at least reasonably comparable to your current kernel (v3.12
current and minimum).
(This as just a user and list regular, not a dev, myself.)
--
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
next prev parent reply other threads:[~2014-01-17 18:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-17 14:18 usrquota Martin Walter
2014-01-17 18:24 ` Duncan [this message]
2014-01-19 16:31 ` usrquota Martin Walter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='pan$195b9$80426a01$8783bbd1$4f640ee9@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox