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
next prev parent 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 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.