All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wido den Hollander <wido@42on.com>
To: Sage Weil <sage@inktank.com>
Cc: Greg Farnum <greg@inktank.com>, ceph-devel@vger.kernel.org
Subject: Re: CephFS First product release discussion
Date: Wed, 06 Mar 2013 18:24:20 +0100	[thread overview]
Message-ID: <51377BC4.5070200@42on.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1303051131010.29462@cobra.newdream.net>

On 03/05/2013 08:33 PM, Sage Weil wrote:
> On Tue, 5 Mar 2013, Wido den Hollander wrote:
>>> Wido, by 'user quota' do you mean something that is uid-based, or would
>>> enforcement on subtree/directory quotas be sufficient for your use cases?
>>> I've been holding out hope that uid-based usage accounting is a thing of
>>> the past and that subtrees are sufficient for real users... in which case
>>> adding enfocement to the existing rstats infrastructure is a very
>>> manageable task.
>>>
>>
>> I mean actual uid-based quotas. That still plays nice with shared environments
>> like Samba or so where you have all homedirectories on a shared filesystems
>> and you set per user quotas. Samba reads out those quotas and propagates them
>> to the (Windows) client.
>
> Does samba propagate the quota information (how much space is
> used/available) or do enforcement on the client side?  (Is client
> enforcement even necessary/useful if the backend will stop writes when the
> quota is exceeded?)
>

I'm not sure. It will at least tell the user how much he/she is using on 
that volume and what the quota is. Not sure who enforces, Samba or the 
filesystem.

 From a quick Google it seems like the filesystem has to enforce the 
quota, Samba doesn't.

>> I know this was a problem with ZFS as well. They also said they could do "per
>> filesystem quotas" so that would be sufficient, but for example NFS doesn't
>> export filesystems mounted in a export, so if you have a bunch of
>> homedirectories on the filesystem and you want to account the usage of each
>> user it's getting kind of hard.
>>
>> This could be solved if the clients directly mounted CephFS though.
>>
>> I'm talking about setups where you have 100k users in a LDAP and they all have
>> their data in a single filesystem and you want to track the usage of each
>> user, that's not an easy task without uid-based quotas.
>
> Wouldn't each user live in a sub- or home directory?  If so, it seems like
> the existing rstats would be sufficient to do the accounting piece; only
> enforcement is missing.
>
>> Running 'du' on each directory would be much faster with Ceph since it
>> accounts tracks the subdirectories and shows their total size with an 'ls
>> -al'.
>>
>> Environments with 100k users also tend to be very dynamic with adding and
>> removing users all the time, so creating separate filesystems for them would
>> be very time consuming.
>>
>> Now, I'm not talking about enforcing soft or hard quotas, I'm just talking
>> about knowing how much space uid X and Y consume on the filesystem.
>
> The part I'm most unclear on is what use cases people have where uid X and
> Y are spread around the file system (not in a single or small set of sub
> directories) and per-user (not, say, per-project) quotas are still
> necessary.  In most environments, users get their own home directory and
> everything lives there...
>

I see a POSIX-filesystem as being partially legacy and a part of that 
legacy is user quotas.

If you want existing applications who rely on userquotas to seamlessly 
switch from NFS to CephFS they will need this to work.

We only talked about userquotas, but groupquotas are just as important.

If you have 10 users where 5 of them are in the group "webdev" and you 
wan't to know how much space is being used by the group "webdev" you 
want to probe the group quotas and you are done.

In some setups like we have users have data in different directories 
outside their home directories / NFS exports. On one machine you just 
run "quota -u <uid>" and you know how much user X is using spread out 
over all the filesystems.

With rstats you would be able to achieve the same with some scripting, 
but that doesn't make the migration seamless.

Wido

> sage
>
>
>>
>> Wido
>>
>>> sage
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
>>
>> --
>> Wido den Hollander
>> 42on B.V.
>>
>> Phone: +31 (0)20 700 9902
>> Skype: contact42on
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Wido den Hollander
42on B.V.

Phone: +31 (0)20 700 9902
Skype: contact42on

  reply	other threads:[~2013-03-06 17:24 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <sfid-H20130305-170326-+024.05-1@marduk.tchpc.tcd.ie>
2013-03-05 17:03 ` CephFS First product release discussion Greg Farnum
2013-03-05 18:08   ` Wido den Hollander
2013-03-05 18:17     ` Greg Farnum
2013-03-05 18:28       ` Sage Weil
2013-03-05 18:36         ` Wido den Hollander
2013-03-05 18:48           ` Jim Schutt
2013-03-05 19:33           ` Sage Weil
2013-03-06 17:24             ` Wido den Hollander [this message]
2013-03-06 19:07             ` Jim Schutt
2013-03-06 19:13               ` CephFS Space Accounting and Quotas (was: CephFS First product release discussion) Greg Farnum
2013-03-06 19:58                 ` CephFS Space Accounting and Quotas Jim Schutt
2013-03-06 20:21                   ` Greg Farnum
2013-03-06 21:28                     ` Jim Schutt
2013-03-06 21:39                       ` Greg Farnum
2013-03-06 23:14                         ` Jim Schutt
2013-03-07  0:18                           ` Greg Farnum
2013-03-07 15:15                             ` Jim Schutt
2013-03-08 22:45                               ` Jim Schutt
2013-03-09  2:05                                 ` Greg Farnum
2013-03-11 14:47                                   ` Jim Schutt
2013-03-11 15:48                                     ` Greg Farnum
2013-03-11 16:48                                       ` Jim Schutt
2013-03-11 16:57                                         ` Greg Farnum
2013-03-11 20:40                                           ` Jim Schutt
2013-03-12 22:34                                             ` Jim Schutt
     [not found]                                               ` <513FAE0F.2010608@sandia.gov>
     [not found]                                                 ` <BE627BF4B6E74BD49037D07821FC1DB9@inktank.com>
     [not found]                                                   ` <5143AA84.50409@sandia.gov>
2013-03-15 23:17                                                     ` Greg Farnum
2013-03-18 14:19                                                       ` Jim Schutt
2013-03-06 21:42                     ` Sage Weil
2013-03-06  5:01   ` [ceph-users] CephFS First product release discussion Neil Levine
     [not found]     ` <CANygib-U_MQi1TMmQuT_Q9MVwPfT+PzJwN=+BMcBK69WuRfu3w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-03-07 13:11       ` Félix Ortega Hortigüela
     [not found]   ` <E0B1337A572647BA9FCC0CE8CA946F42-4GqslpFJ+cxBDgjK7y7TUQ@public.gmane.org>
2013-03-07 11:54     ` Jimmy Tang

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=51377BC4.5070200@42on.com \
    --to=wido@42on.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=greg@inktank.com \
    --cc=sage@inktank.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.