public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
* separate project quota from group quota (questions, design issues)
@ 2010-09-04  8:00 Arkadiusz Miskiewicz
  2010-09-04 17:13 ` Michael Monnerie
  2010-09-04 23:30 ` Christoph Hellwig
  0 siblings, 2 replies; 7+ messages in thread
From: Arkadiusz Miskiewicz @ 2010-09-04  8:00 UTC (permalink / raw)
  To: xfs


Dave thinks that this subject should be discussed first here.

My goal is to be able to use user, group and project quota at the same time. 
Example usage is a web hosting company which gives some space for customer 
(group quota), customer splits it into accounts (user quota) and then each 
account can have multiple vhosts with own quota (project quota).

Since on-disk format keeps group and project quota separate already then why 
not making it usable for a user as separate things, too?

I started doing that by splitting every group+project handling code into 
separate group and project one. Added superblock field for project quota. New 
feature flag (SEPARATEPQUOTA).

If old filesystem (for SEPARATEQUOTA) is mounted then I'll simply load 
sb_gquotino into mp->m_sb.sb_pquotino which I think is enough to handle old fs 
(since new kernel operates on separate structures for project quota).

New filesystem (without quota inodes allocated yet), when mounted, gets new 
quota inode allocated for project quota and SEPARATEQUOTA feature bit set.

Converting old fs to separate quota isn't currently solved. User could need 
two choices - use old group quota still as group or old group as new project 
quota. Not sure how to handle these yet. 
Also, quota data is keept in extents and extents have d_flags representing 
type of quota (user/group/proj). Now what happens (in current code) with 
extents of group/project quota inode if mouting once with grpquota and once 
with projquota? Are the other extent entries ignored? (like mounted with group 
-> extents with proj type ignored or deleted or something else?). 

There is also issue with kernel generic quota interface fs_quota_stat which 
doesn't handle third quota at all. It simply won't be able to operate on 
project quota (as I guess it isn't able to do that even now).

Initial, not working yet (due to locking issues) patch is here (on top of 
projid32bit patch actually, but both features are unrelated):
http://carme.pld-linux.org/~arekm/xfs-parallel-grp-prj-quota-2.patch

My current problem is lack of understanding of locking issues here:
http://pastebin.com/brBHPavR

How locking should look like when there is also project quota? Lines 1390-1397 
and 1419-1428.

With current code as pasted on pastebin mount hangs trying to do lock on 1426 
line which was unlocked just few lines before.
-- 
Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: separate project quota from group quota (questions, design issues)
  2010-09-04  8:00 separate project quota from group quota (questions, design issues) Arkadiusz Miskiewicz
@ 2010-09-04 17:13 ` Michael Monnerie
  2010-09-04 23:30 ` Christoph Hellwig
  1 sibling, 0 replies; 7+ messages in thread
From: Michael Monnerie @ 2010-09-04 17:13 UTC (permalink / raw)
  To: xfs


[-- Attachment #1.1: Type: Text/Plain, Size: 2411 bytes --]

On Samstag, 4. September 2010 Arkadiusz Miskiewicz wrote:
> My goal is to be able to use user, group and project quota at the
>  same time.  Example usage is a web hosting company which gives some
>  space for customer (group quota), customer splits it into accounts
>  (user quota) and then each account can have multiple vhosts with own
>  quota (project quota).
 
Nice idea. I'd also like that, but also mixed:
userdir1 -> user quota
userdir2
prjdir1 -> project quota
prjdir2
groupdir1 -> group quota for a group of users 
groupdir2 -> for a group of projects

From what you write, I'm sure you can't mix groups with users and 
projects, instead it needs to be defined at mount time. It would be very 
good if that can be mixed at the same time.

I'd like to say users1-5 can have 500G each, together 2T max. And 
projects can have 2T each, but project1+2 together max. 2T. users6-9 can 
have 100G each, together 100G max. Currently I defined everything as a 
project, and manually check quotas for groups of projects if they cross 
the "group max" border.


But I'd also be very interested in what you write above - it would be a 
very welcome expansion of quotas which seems good. Just a question for 
setup: We use all dirs side-by-side like
domain1
domain2
 |- prj1
 |- prj2
domain3
Now customer1 can have domain1 and domain2, customer2 has domain3. prj1 
and prj2 can have prjquota. Am I right that this is possible with your 
approach? Seems like, and I just want to ask to be sure I understand you 
correctly.

Just how would you account that? Say each customer gets 20G, each domain 
20G, projects 10G each. When above customer1 has 12G in domain1, he has 
left 8G for domain2. Are projects also limited to 8G in sum, or is their 
10G limit the one that's valid? If prj1 has 5G, is the 8G-5G=3G what's 
available for domain2, or are projects completely separate?
I believe there are lots of variations and some people would like to 
have it accounted, some not. Can this ever be solved?

-- 
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc

it-management Internet Services
http://proteger.at [gesprochen: Prot-e-schee]
Tel: 0660 / 415 65 31

****** Aktuelles Radiointerview! ******
http://www.it-podcast.at/aktuelle-sendung.html

// Wir haben im Moment zwei Häuser zu verkaufen:
// http://zmi.at/langegg/
// http://zmi.at/haus2009/

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: separate project quota from group quota (questions, design issues)
  2010-09-04  8:00 separate project quota from group quota (questions, design issues) Arkadiusz Miskiewicz
  2010-09-04 17:13 ` Michael Monnerie
@ 2010-09-04 23:30 ` Christoph Hellwig
  2010-09-05 17:24   ` Arkadiusz Miskiewicz
  2010-09-06  1:16   ` Dave Chinner
  1 sibling, 2 replies; 7+ messages in thread
From: Christoph Hellwig @ 2010-09-04 23:30 UTC (permalink / raw)
  To: Arkadiusz Miskiewicz; +Cc: xfs

Thanks for doing this work Arek, I think it will be useful for some
users and defintively is cleaners than what we have now.

> I started doing that by splitting every group+project handling code into 
> separate group and project one. Added superblock field for project quota. New 
> feature flag (SEPARATEPQUOTA).

Ok.

> If old filesystem (for SEPARATEQUOTA) is mounted then I'll simply load 
> sb_gquotino into mp->m_sb.sb_pquotino which I think is enough to handle old fs 
> (since new kernel operates on separate structures for project quota).

Do you mean an old filesystem without the SEPARATEQUOTA bit set here?

> New filesystem (without quota inodes allocated yet), when mounted, gets new 
> quota inode allocated for project quota and SEPARATEQUOTA feature bit set.

I think we need the SEPARATEQUOTA bit set explicitly by
mkfs.xfs/xfs_admin.  But once we start using project quotas with the
bit set the above sounds fine.

> Converting old fs to separate quota isn't currently solved. User could need 
> two choices - use old group quota still as group or old group as new project 
> quota. Not sure how to handle these yet. 

We know what sb_gquotino is used for currently from sb_qflags.  If it's
used for group quota we can simply set the SEPARATEQUOTA bit and we're
done.  To convert a filesystem using project quotas to SEPARATEQUOTA
sb_gquotino needs to be cleared and instead the new sb_pquotino field
needs to point to the project quota inode.


Need to go now, I'll answer to your other questions once I had some more
time to review them.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: separate project quota from group quota (questions, design issues)
  2010-09-04 23:30 ` Christoph Hellwig
@ 2010-09-05 17:24   ` Arkadiusz Miskiewicz
  2010-09-06  1:12     ` Dave Chinner
  2010-09-06  1:16   ` Dave Chinner
  1 sibling, 1 reply; 7+ messages in thread
From: Arkadiusz Miskiewicz @ 2010-09-05 17:24 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: xfs

On Sunday 05 of September 2010, Christoph Hellwig wrote:
> Thanks for doing this work Arek, I think it will be useful for some
> users and defintively is cleaners than what we have now.
> 
> > I started doing that by splitting every group+project handling code into
> > separate group and project one. Added superblock field for project quota.
> > New feature flag (SEPARATEPQUOTA).
> 
> Ok.
> 
> > If old filesystem (for SEPARATEQUOTA) is mounted then I'll simply load
> > sb_gquotino into mp->m_sb.sb_pquotino which I think is enough to handle
> > old fs (since new kernel operates on separate structures for project
> > quota).
> 
> Do you mean an old filesystem without the SEPARATEQUOTA bit set here?

Yes. When trying to load existing project quota inode in 
xfs_qm_init_quotainos() I'm doing:

+                       if (!xfs_sb_version_hasseparatepquota(&mp->m_sb)) {
+                               ASSERT(!XFS_IS_GQUOTA_ON(mp));
+                               mp->m_sb.sb_pquotino = mp->m_sb.sb_gquotino;
+                               mp->m_sb.sb_gquotino = 0;
+                       }

While xfs_mod_sb() now does:

        /*                                                                                                                                                   
         * Filesystem has no separatepquota turned on,                                                                                                       
         * so we need to store project quota in group                                                                                                        
         * quota inode on disk.                                                                                                                              
         */                                                                                                                                                  
        if (!xfs_sb_version_hasseparatepquota(&mp->m_sb)) {                                                                                                  
                mp->m_sb.sb_gquotino = mp->m_sb.sb_pquotino;                                                                                                 
                mp->m_sb.sb_pquotino = 0;                                                                                                                    
        }  

       xfs_sb_to_disk(XFS_BUF_TO_SBP(bp), &mp->m_sb, fields);

 [...]
        /*
         * Restore original in-memory project quota inode state.
         */
        if (!xfs_sb_version_hasseparatepquota(&mp->m_sb)) {                                                                                                  
                mp->m_sb.sb_pquotino = mp->m_sb.sb_gquotino;                                                                                                 
                mp->m_sb.sb_gquotino = 0;                                                                                                                    
        }     

so in-memory sb_pquotaino is always used for project quota (regardless of 
SEPARATEPQUOTA feature) while on-disk is depending on SEPARATEPQUOTA feature 
bit. SB modify part is untested yet.

> > Converting old fs to separate quota isn't currently solved. User could
> > need two choices - use old group quota still as group or old group as
> > new project quota. Not sure how to handle these yet.
> 
> We know what sb_gquotino is used for currently from sb_qflags.  If it's
> used for group quota we can simply set the SEPARATEQUOTA bit and we're
> done.  To convert a filesystem using project quotas to SEPARATEQUOTA
> sb_gquotino needs to be cleared and instead the new sb_pquotino field
> needs to point to the project quota inode.

Ok, I'll add new "upgrade <feature>" command to xfs_db (and call it from 
xfs_admin, too) where for now the only feature will be "separatepquota" one.

-- 
Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: separate project quota from group quota (questions, design issues)
  2010-09-05 17:24   ` Arkadiusz Miskiewicz
@ 2010-09-06  1:12     ` Dave Chinner
  2010-09-06  6:28       ` Arkadiusz Miskiewicz
  0 siblings, 1 reply; 7+ messages in thread
From: Dave Chinner @ 2010-09-06  1:12 UTC (permalink / raw)
  To: Arkadiusz Miskiewicz; +Cc: Christoph Hellwig, xfs

On Sun, Sep 05, 2010 at 07:24:35PM +0200, Arkadiusz Miskiewicz wrote:
> On Sunday 05 of September 2010, Christoph Hellwig wrote:
> > Thanks for doing this work Arek, I think it will be useful for some
> > users and defintively is cleaners than what we have now.
> > 
> > > I started doing that by splitting every group+project handling code into
> > > separate group and project one. Added superblock field for project quota.
> > > New feature flag (SEPARATEPQUOTA).
> > 
> > Ok.
> > 
> > > If old filesystem (for SEPARATEQUOTA) is mounted then I'll simply load
> > > sb_gquotino into mp->m_sb.sb_pquotino which I think is enough to handle
> > > old fs (since new kernel operates on separate structures for project
> > > quota).
> > 
> > Do you mean an old filesystem without the SEPARATEQUOTA bit set here?
> 
> Yes. When trying to load existing project quota inode in 
> xfs_qm_init_quotainos() I'm doing:
> 
> +                       if (!xfs_sb_version_hasseparatepquota(&mp->m_sb)) {
> +                               ASSERT(!XFS_IS_GQUOTA_ON(mp));
> +                               mp->m_sb.sb_pquotino = mp->m_sb.sb_gquotino;
> +                               mp->m_sb.sb_gquotino = 0;
> +                       }
> 
> While xfs_mod_sb() now does:
> 
>         /*
>          * Filesystem has no separatepquota turned on,
>          * so we need to store project quota in group
>          * quota inode on disk.
>          */
>         if (!xfs_sb_version_hasseparatepquota(&mp->m_sb)) {
>                 mp->m_sb.sb_gquotino = mp->m_sb.sb_pquotino;
>                 mp->m_sb.sb_pquotino = 0;
>         }
>
>        xfs_sb_to_disk(XFS_BUF_TO_SBP(bp), &mp->m_sb, fields);
>
>  [...]
>         /*
>          * Restore original in-memory project quota inode state.
>          */
>         if (!xfs_sb_version_hasseparatepquota(&mp->m_sb)) {
>                 mp->m_sb.sb_pquotino = mp->m_sb.sb_gquotino;
>                 mp->m_sb.sb_gquotino = 0;
>         }

I don't think that is safe - we can have concurrent access to the
in-core superblock (mp->m_sb) without locking the superblock, so
something that races with xfs_mod_sb() looking up project quota
could die a horrible death here.

The only time that you should need to do this juggling is when the
quota inode changes. That is, when the XFS_SB_GQUOTINO field is
set. Otherwise the field won't be modified and so we don't need to
convert the values. That only occurs when quotas are being
initialised (xfs_qm_qino_alloc()) during mount, so in that case
there can't be any concurrent operations occurring. Hence swizzling
the inode fields only when the XFS_SB_GQUOTINO filed is set should
be safe.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: separate project quota from group quota (questions, design issues)
  2010-09-04 23:30 ` Christoph Hellwig
  2010-09-05 17:24   ` Arkadiusz Miskiewicz
@ 2010-09-06  1:16   ` Dave Chinner
  1 sibling, 0 replies; 7+ messages in thread
From: Dave Chinner @ 2010-09-06  1:16 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: xfs

On Sat, Sep 04, 2010 at 07:30:53PM -0400, Christoph Hellwig wrote:
> Thanks for doing this work Arek, I think it will be useful for some
> users and defintively is cleaners than what we have now.
> 
> > I started doing that by splitting every group+project handling code into 
> > separate group and project one. Added superblock field for project quota. New 
> > feature flag (SEPARATEPQUOTA).
> 
> Ok.
> 
> > If old filesystem (for SEPARATEQUOTA) is mounted then I'll simply load 
> > sb_gquotino into mp->m_sb.sb_pquotino which I think is enough to handle old fs 
> > (since new kernel operates on separate structures for project quota).
> 
> Do you mean an old filesystem without the SEPARATEQUOTA bit set here?
> 
> > New filesystem (without quota inodes allocated yet), when mounted, gets new 
> > quota inode allocated for project quota and SEPARATEQUOTA feature bit set.
> 
> I think we need the SEPARATEQUOTA bit set explicitly by
> mkfs.xfs/xfs_admin.  But once we start using project quotas with the
> bit set the above sounds fine.

Agreed - we can't set the bit by default until the kernel has
suppoerted the feature for some time. A user who upgrades from a
kernel that doesn't support separate quotas can't downgrade if the
bit is automatically set if there are problems (and the problems
requiring downgrade might be completely unrelated to XFS).

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: separate project quota from group quota (questions, design issues)
  2010-09-06  1:12     ` Dave Chinner
@ 2010-09-06  6:28       ` Arkadiusz Miskiewicz
  0 siblings, 0 replies; 7+ messages in thread
From: Arkadiusz Miskiewicz @ 2010-09-06  6:28 UTC (permalink / raw)
  To: Dave Chinner; +Cc: Christoph Hellwig, xfs

On Monday 06 of September 2010, Dave Chinner wrote:
> On Sun, Sep 05, 2010 at 07:24:35PM +0200, Arkadiusz Miskiewicz wrote:

> >          * Restore original in-memory project quota inode state.
> >          */
> >         
> >         if (!xfs_sb_version_hasseparatepquota(&mp->m_sb)) {
> >         
> >                 mp->m_sb.sb_pquotino = mp->m_sb.sb_gquotino;
> >                 mp->m_sb.sb_gquotino = 0;
> >         
> >         }
> 
> I don't think that is safe - we can have concurrent access to the
> in-core superblock (mp->m_sb) without locking the superblock, so
> something that races with xfs_mod_sb() looking up project quota
> could die a horrible death here.

I was thinking about working on a copy, too, like this
+       xfs_sb_t        sb_copy;
[...]
+       memcpy(&sb_copy, from, sizeof(sb_copy));
+       from_ptr = (xfs_caddr_t)&sb_copy;
+
+       if (!xfs_sb_version_hasseparatepquota(from) &&
+                       (sb_copy.sb_qflags & XFS_PQUOTA_ACCT)) {
+               sb_copy.sb_gquotino = from->sb_pquotino;
+               sb_copy.sb_pquotino = 0;
+
+       } 

> 
> The only time that you should need to do this juggling is when the
> quota inode changes. That is, when the XFS_SB_GQUOTINO field is
> set. Otherwise the field won't be modified and so we don't need to
> convert the values. That only occurs when quotas are being
> initialised (xfs_qm_qino_alloc()) during mount, so in that case
> there can't be any concurrent operations occurring. Hence swizzling
> the inode fields only when the XFS_SB_GQUOTINO filed is set should
> be safe.

Unfortunately it turns out that I need to convert sb_qflags, too (see below)
and sb_qflags seem to be changes in few different places, so xfs_mod_sb()
looks a good place to do a conversion for this.

sb_qflags come into play. Old XFS_OQUOTA_CHKD and
XFS_PQUOTA_CHKD are no longer used by kernel but existing filesystems
can have these, so I'm going to translate old into new flags currently
in xfs_sb_from_disk() and vice versa in xfs_mod_sb().

@@ -575,6 +588,26 @@ xfs_sb_from_disk(
        to->sb_logsunit = be32_to_cpu(from->sb_logsunit);
        to->sb_features2 = be32_to_cpu(from->sb_features2);
        to->sb_bad_features2 = be32_to_cpu(from->sb_bad_features2);
+       to->sb_pquotino = be64_to_cpu(from->sb_pquotino);
+
+       /*
+        * Convert old quota to separatepquota flags.
+        */
+       if (to->sb_qflags & XFS_OQUOTA_CHKD_NOTUSED) {
+               if (to->sb_qflags & XFS_GQUOTA_ACCT) {
+                       to->sb_qflags &= ~XFS_OQUOTA_CHKD_NOTUSED;
+                       to->sb_qflags |= XFS_GQUOTA_CHKD;
+               } else if (to->sb_qflags & XFS_PQUOTA_ACCT) {
+                       to->sb_qflags &= ~XFS_PQUOTA_CHKD_NOTUSED;
+                       to->sb_qflags |= XFS_PQUOTA_CHKD;
+               }
+       }
+
+       if (!xfs_sb_version_hasseparatepquota(to) &&
+                       (to->sb_qflags & XFS_PQUOTA_ACCT)) {
+               to->sb_pquotino = to->sb_gquotino;
+               to->sb_gquotino = 0;
+       }
 }

New flags are going to be like this:

 #define XFS_UQUOTA_ENFD        0x0002  /* user quota limits enforced */                                                                                     
 #define XFS_UQUOTA_CHKD        0x0004  /* quotacheck run on usr quotas */                                                                                   
 #define XFS_PQUOTA_ACCT        0x0008  /* project quota accounting ON */                                                                                    
-#define XFS_OQUOTA_ENFD        0x0010  /* other (grp/prj) quota limits enforced */                                                                          
-#define XFS_OQUOTA_CHKD        0x0020  /* quotacheck run on other (grp/prj) quotas */                                                                       
+#define XFS_OQUOTA_ENFD_NOTUSED        0x0010  /* other (grp/prj) quota limits enforced (NO LONGER USED)*/                                                  
+#define XFS_OQUOTA_CHKD_NOTUSED        0x0020  /* quotacheck run on other (grp/prj) quotas (NO LONGER USED)*/                                               
 #define XFS_GQUOTA_ACCT        0x0040  /* group quota accounting ON */                                                                                      
+#define XFS_GQUOTA_ENFD        0x0080  /* group quota limits enforced */                                                                                    
+#define XFS_GQUOTA_CHKD        0x0100  /* group quota accoungint ON */                                                                                      
+#define XFS_PQUOTA_CHKD        0x0200  /* quotacheck run on project quotas */                                                                               
+#define XFS_PQUOTA_ENFD        0x0400  /* project quota limits enforced */  


> Cheers,
> 
> Dave.


-- 
Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2010-09-06  6:27 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-09-04  8:00 separate project quota from group quota (questions, design issues) Arkadiusz Miskiewicz
2010-09-04 17:13 ` Michael Monnerie
2010-09-04 23:30 ` Christoph Hellwig
2010-09-05 17:24   ` Arkadiusz Miskiewicz
2010-09-06  1:12     ` Dave Chinner
2010-09-06  6:28       ` Arkadiusz Miskiewicz
2010-09-06  1:16   ` Dave Chinner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox