public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Chandra Seetharaman <sekharan@us.ibm.com>
Cc: xfs@oss.sgi.com
Subject: Re: [RFC v6 PATCH 3/5] xfs: Add pquotaino to on-disk super block
Date: Thu, 23 Aug 2012 10:25:53 +1000	[thread overview]
Message-ID: <20120823002553.GT19235@dastard> (raw)
In-Reply-To: <1345678248.2260.31.camel@chandra-lucid.austin.ibm.com>

On Wed, Aug 22, 2012 at 06:30:48PM -0500, Chandra Seetharaman wrote:
> On Wed, 2012-08-15 at 12:09 +1000, Dave Chinner wrote:
> > On Fri, Jul 20, 2012 at 06:02:41PM -0500, Chandra Seetharaman wrote:
.....
> > > +		if (to->sb_qflags & (XFS_OQUOTA_ENFD | XFS_OQUOTA_CHKD)) {
> > > +			xfs_notice(mp, "Super block has XFS_OQUOTA bits with "
> > > +			"version NO_OQUOTA. Fixing it.\n");
> > > +			to->sb_qflags &= ~(XFS_OQUOTA_ENFD | XFS_OQUOTA_CHKD);
> > > +		}
> > > +		to->sb_pquotino = be64_to_cpu(from->sb_pquotino);
> > 
> > So we have a feature bit set, but old quota bits set. How can that
> > happen?
> > 
> > If it does occur, doesn't that mean we cannot trust the group or
> > project quotas to be correct, so at minimum this case needs to
> > trigger a quotacheck for both group and project quotas?
> 
> Sure, will do a quotacheck here. I just call xfs_qm_quotacheck() and
> fail if it fails ?

The quotacheck occurs later in the mount process. IIRC, just
clearing the relevant XFS_[UGP]QUOTA_CHKD flag will cause a quota
check to be done at the appropriate time.

> > > +		}
> > > +		if (to->sb_qflags & XFS_OQUOTA_ENFD)
> > > +			to->sb_qflags |= (to->sb_qflags & XFS_PQUOTA_ACCT) ?
> > > +					XFS_PQUOTA_ENFD : XFS_GQUOTA_ENFD;
> > > +		if (to->sb_qflags & XFS_OQUOTA_CHKD)
> > > +			to->sb_qflags |= (to->sb_qflags & XFS_PQUOTA_ACCT) ?
> > > +					XFS_PQUOTA_CHKD : XFS_GQUOTA_CHKD;
> > 
> > what do you do if both XFS_PQUOTA_ACCT and XFS_GQUOTA_ACCT are set?
> > i.e. both quotas were active even though the feature bit wasn't set?
> 
> I will do a check on both flags being set and do a quotacheck ?

Yes, I think that will be sufficient with an appropriate warning.

> > >  		} else {
> > >  			switch (size) {
> > >  			case 2:
> > > @@ -759,6 +803,12 @@ reread:
> > >  		goto reread;
> > >  	}
> > >  
> > > +	if (!xfs_sb_version_has_no_oquota(&mp->m_sb) &&
> > > +			XFS_IS_PQUOTA_ON(mp)) {
> > > +		mp->m_sb.sb_pquotino = mp->m_sb.sb_gquotino;
> > > +		mp->m_sb.sb_gquotino = NULLFSINO;
> > > +	}
> > 
> > why this is necessary? Didn't the earlier xfs_sb_from_disk() call
> > deal with this?
> 
> The call in xfs_sb_from_disk() only sets if the superblock has pquota
> already. 
> 
> This sets up the fields when superblock didn't have it, but the user
> specified pquota as a mount option.

Ah, so it is the same as the previous case I mentioned needs a
comment. Can you document this here as well?

> > > @@ -838,19 +840,22 @@ xfs_qm_qino_alloc(
> > >  		ASSERT((sbfields & (XFS_SB_VERSIONNUM | XFS_SB_UQUOTINO |
> > >  				   XFS_SB_GQUOTINO | XFS_SB_QFLAGS)) ==
> > >  		       (XFS_SB_VERSIONNUM | XFS_SB_UQUOTINO |
> > > -			XFS_SB_GQUOTINO | XFS_SB_QFLAGS));
> > > +			XFS_SB_GQUOTINO | XFS_SB_PQUOTINO | XFS_SB_QFLAGS));
> > 
> > Did you test this with CONFIG_XFS_DEBUG=y? It will always fail
> > because you didn't add XFS_SB_PQUOTINO to the sbfields mask....
> 
> In my box, I always had problems with DEBUG :(... So, I stopped testing
> with it.

Hmmm. DEBUG shouldn't cause you any extra problems unless there
really is something wrong - I run almost exclusively with DEBUG
enabled and I rarely have problems with spurious ASSERT()s
triggering. It's better to report spurious/unrelated ASSERT()
failures than to ignore them. 

[ FWIW, the only time I turnoff DEBUG is when I'm doing performance
benchmarking to get maximum numbers - DEBUG drops metadata
throughput by about 25% and changes allocation patterns to improve
code coverage, so the results of performance testing with DEBUG are
not really representative. ]

In the mean time, run with DEBUG without your patches and exclude
all the tests that trigger problems on a vanilla kernel (e.g. via
'echo 068 >> expunged') and then run with you patches. Any new
failures are likely to be caused by your patches and need to be
analysed.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

  reply	other threads:[~2012-08-23  0:25 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-20 23:02 [RFC v6 PATCH 0/5] xfs: Allow pquota and gquota to be used together Chandra Seetharaman
2012-07-20 23:02 ` [RFC v6 PATCH 1/5] xfs: Remove incore use of XFS_OQUOTA_ENFD and XFS_OQUOTA_CHKD Chandra Seetharaman
2012-08-14 22:46   ` Dave Chinner
2012-08-22 22:53     ` Chandra Seetharaman
2012-09-13  7:56       ` Christoph Hellwig
2012-09-13 20:37         ` Chandra Seetharaman
2012-07-20 23:02 ` [RFC v6 PATCH 2/5] xfs: Add pquota fields where gquota is used Chandra Seetharaman
2012-08-15  1:15   ` Dave Chinner
2012-08-22 22:56     ` Chandra Seetharaman
2012-07-20 23:02 ` [RFC v6 PATCH 3/5] xfs: Add pquotaino to on-disk super block Chandra Seetharaman
2012-08-15  2:09   ` Dave Chinner
2012-08-22 23:30     ` Chandra Seetharaman
2012-08-23  0:25       ` Dave Chinner [this message]
2012-07-20 23:02 ` [RFC v6 PATCH 4/5] xfs: Add proper versioning support to fs_quota_stat Chandra Seetharaman
2012-08-15  2:32   ` Dave Chinner
2012-08-22 23:32     ` Chandra Seetharaman
2012-07-20 23:03 ` [RFC v6 PATCH 5/5] xfs: Add a new field to fs_quota_stat to get pquota information Chandra Seetharaman
2012-08-15  2:37   ` Dave Chinner
2012-08-22 23:40     ` Chandra Seetharaman

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=20120823002553.GT19235@dastard \
    --to=david@fromorbit.com \
    --cc=sekharan@us.ibm.com \
    --cc=xfs@oss.sgi.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