From: Gordan Bobic <gordan@bobich.net>
To: Hugo Mills <hugo-lkml@carfax.org.uk>,
Josef Bacik <josef@redhat.com>,
linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
chris.mason@oracle.com, hch@lst.de, ssorce@redhat.com
Subject: Re: What to do about subvolumes?
Date: Wed, 01 Dec 2010 16:48:02 +0000 [thread overview]
Message-ID: <4CF67C42.9080406@bobich.net> (raw)
In-Reply-To: <20101201163800.GA4087@carfax.org.uk>
Hugo Mills wrote:
> On Wed, Dec 01, 2010 at 09:21:36AM -0500, Josef Bacik wrote:
>> === Quotas ===
>>
>> This is a huge topic in and of itself, but Christoph mentioned wanting to have
>> an idea of what we wanted to do with it, so I'm putting it here. There are
>> really 2 things here
>>
>> 1) Limiting the size of subvolumes. This is really easy for us, just create a
>> subvolume and at creation time set a maximum size it can grow to and not let it
>> go farther than that. Nice, simple and straightforward.
>>
>> 2) Normal quotas, via the quota tools. This just comes down to how do we want
>> to charge users, do we want to do it per subvolume, or per filesystem. My vote
>> is per filesystem. Obviously this will make it tricky with snapshots, but I
>> think if we're just charging the diff's between the original volume and the
>> snapshot to the user then that will be the easiest for people to understand,
>> rather than making a snapshot all of a sudden count the users currently used
>> quota * 2.
>
> This is going to be tricky to get the semantics right, I suspect.
>
> Say you've created a subvolume, A, containing 10G of Useful Stuff
> (say, a base image for VMs). This counts 10G against your quota. Now,
> I come along and snapshot that subvolume (as a writable subvolume) --
> call it B. This is essentially free for me, because I've got a COW
> copy of your subvolume (and the original counts against your quota).
>
> If I now modify a file in subvolume B, the full modified section
> goes onto my quota. This is all well and good. But what happens if you
> delete your subvolume, A? Suddenly, I get lumbered with 10G of extra
> files. Worse, what happens if someone else had made a snapshot of A,
> too? Who gets the 10G added to their quota, me or them? What if I'd
> filled up my quota? Would that stop you from deleting your copy,
> because my copy can't be charged against my quota? Would I just end up
> unexpectedly 10G over quota?
>
> This is a whole gigantic can of worms, as far as I can see, and I
> don't think it's going to be possible to implement quotas, even on a
> filesystem level, until there's some good and functional model for
> dealing with all the implications of COW copies. :(
I would argue that a simple and probably correct solution is to have the
files count toward the quota of everyone who has a COW copy. i.e. if I
have a volume A and you make a snapshot B, the du content of B should
count toward your quota as well, rather than being "free". I don't see
any reason why this would not be the correct and intuitive way to do it.
Simply treat it as you would transparent block-level deduplication.
Gordan
next prev parent reply other threads:[~2010-12-01 16:48 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-01 14:21 What to do about subvolumes? Josef Bacik
2010-12-01 14:50 ` Mike Hommey
2010-12-01 14:51 ` C Anthony Risinger
2010-12-01 16:01 ` Chris Mason
2010-12-01 16:03 ` C Anthony Risinger
2010-12-01 16:13 ` Chris Mason
2010-12-01 16:31 ` Mike Hommey
2010-12-09 19:53 ` Martin Steigerwald
2010-12-01 16:00 ` Chris Mason
2010-12-01 16:38 ` Hugo Mills
2010-12-01 16:48 ` Gordan Bobic [this message]
2010-12-01 16:52 ` Mike Hommey
2010-12-01 16:52 ` C Anthony Risinger
2010-12-01 17:38 ` Josef Bacik
2010-12-01 19:35 ` Hugo Mills
2010-12-01 20:24 ` Freddie Cash
2010-12-01 21:28 ` Hugo Mills
2010-12-01 23:32 ` Freddie Cash
2010-12-02 4:46 ` Mike Fedyk
2010-12-01 18:33 ` Goffredo Baroncelli
2010-12-01 18:36 ` Josef Bacik
2010-12-01 18:48 ` C Anthony Risinger
2010-12-01 18:52 ` C Anthony Risinger
2010-12-01 19:08 ` Goffredo Baroncelli
2010-12-01 19:44 ` J. Bruce Fields
2010-12-01 19:54 ` Josef Bacik
2010-12-01 20:00 ` J. Bruce Fields
2010-12-01 20:09 ` Josef Bacik
2010-12-01 20:16 ` J. Bruce Fields
2010-12-02 1:52 ` Michael Vrable
2010-12-03 20:53 ` J. Bruce Fields
2010-12-01 20:03 ` Jeff Layton
2010-12-01 20:46 ` Goffredo Baroncelli
2010-12-01 21:06 ` Jeff Layton
2010-12-02 9:26 ` Arne Jansen
2010-12-02 9:49 ` Arne Jansen
2010-12-02 16:11 ` Chris Mason
2010-12-02 17:14 ` David Pottage
2010-12-03 20:56 ` J. Bruce Fields
2010-12-03 2:43 ` Phillip Susi
2011-01-31 2:40 ` Ian Kent
2010-12-03 4:25 ` Chris Ball
2010-12-03 14:00 ` Josef Bacik
2010-12-03 21:45 ` Josef Bacik
2010-12-03 22:16 ` J. Bruce Fields
2010-12-03 22:27 ` Dave Chinner
2010-12-03 22:29 ` Chris Mason
2010-12-03 22:45 ` J. Bruce Fields
2010-12-03 23:01 ` Andreas Dilger
2010-12-06 16:48 ` J. Bruce Fields
2010-12-08 6:39 ` Andreas Dilger
2010-12-08 23:07 ` Neil Brown
2010-12-09 4:41 ` Andreas Dilger
2010-12-09 15:19 ` J. Bruce Fields
2010-12-07 16:52 ` hch
2010-12-07 20:45 ` J. Bruce Fields
2010-12-07 16:51 ` Christoph Hellwig
2010-12-07 17:02 ` Trond Myklebust
2010-12-08 17:16 ` Andreas Dilger
2010-12-08 17:27 ` J. Bruce Fields
2010-12-08 21:18 ` Andreas Dilger
2010-12-04 21:58 ` Mike Fedyk
2010-12-06 14:27 ` Josef Bacik
2011-01-31 2:56 ` Ian Kent
2010-12-07 16:48 ` Christoph Hellwig
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=4CF67C42.9080406@bobich.net \
--to=gordan@bobich.net \
--cc=chris.mason@oracle.com \
--cc=hch@lst.de \
--cc=hugo-lkml@carfax.org.uk \
--cc=josef@redhat.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=ssorce@redhat.com \
/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;
as well as URLs for NNTP newsgroup(s).