From: Ben Myers <bpm@sgi.com>
To: Chandra Seetharaman <sekharan@us.ibm.com>
Cc: xfs@oss.sgi.com
Subject: Re: [RFC v3 PATCH 1/4] xfs: Remove incore use of XFS_OQUOTA_ENFD and XFS_OQUOTA_CHKD
Date: Fri, 17 Feb 2012 12:39:02 -0600 [thread overview]
Message-ID: <20120217183902.GE7762@sgi.com> (raw)
In-Reply-To: <1329149157.2213.55.camel@chandra-lucid.austin.ibm.com>
Hey Chandra,
On Mon, Feb 13, 2012 at 10:05:57AM -0600, Chandra Seetharaman wrote:
> On Fri, 2012-02-10 at 18:41 -0600, Ben Myers wrote:
>
> <snip>
>
> > > @@ -657,6 +686,7 @@ xfs_sb_to_disk(
> > >
> > > fields &= ~(1LL << f);
> > > }
> > > + from->sb_qflags = saved_qflags;
> >
> > I am disgusted that you should have to save the sb_qflags like this.
> > After reading this 'fields' loop in xfs_sb_to_disk along with all the
> > related crap I am actually feeling a little nauseous.
>
> Let me know if you have any other solutions. I am open for it.
How would you feel about something like this?
@@ -622,6 +636,7 @@ xfs_sb_to_disk(
xfs_sb_field_t f;
int first;
int size;
+ __uint16_t tmp16;
ASSERT(fields);
if (!fields)
@@ -636,6 +651,27 @@ xfs_sb_to_disk(
if (size == 1 || xfs_sb_info[f].type == 1) {
memcpy(to_ptr + first, from_ptr + first, size);
+ } else if (f == XFS_SBS_QFLAGS) {
+ /*
+ * The in-core version of sb_qflags do not have
+ * XFS_OQUOTA_* flags, whereas the on-disk version
+ * does. Save the in-core sb_qflags temporarily,
+ * removing the new XFS_{PG}QUOTA_* flags and re-apply
+ * the old on-disk flags. This is a temporary
+ * situation until the on-disk flags are updated.
+ */
+ tmp16 = from->sb_qflags &
+ ~(XFS_PQUOTA_ENFD | XFS_PQUOTA_CHKD |
+ XFS_GQUOTA_ENFD | XFS_GQUOTA_CHKD);
+
+ if (from->sb_qflags &
+ (XFS_PQUOTA_ENFD | XFS_GQUOTA_ENFD))
+ tmp16 |= XFS_OQUOTA_ENFD;
+ if (from->sb_qflags &
+ (XFS_PQUOTA_CHKD | XFS_GQUOTA_CHKD))
+ tmp16 |= XFS_OQUOTA_CHKD;
+
+ *(__be16 *)(to_ptr + first) = cpu_to_be16(tmp16);
} else {
switch (size) {
case 2:
This way we needn't worry about any change (or locking) of the incore
superblock sb_qflags.
> > I don't know why in XFS we seem to feel the need to do everything in the
> > most complicated way possible.
I suppose they were trying to cut down on conditionals on fields... maybe
something that could be done better at compile time... someday.
Regards,
Ben
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2012-02-17 18:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-23 17:31 [RFC v3 PATCH 0/4] xfs: Allow pquota and gquota to be used together Chandra Seetharaman
2012-01-23 17:32 ` [RFC v3 PATCH 1/4] xfs: Remove incore use of XFS_OQUOTA_ENFD and XFS_OQUOTA_CHKD Chandra Seetharaman
2012-01-31 21:41 ` [NOTES] " Phil White
2012-02-11 0:41 ` Ben Myers
2012-02-13 16:05 ` Chandra Seetharaman
2012-02-17 18:39 ` Ben Myers [this message]
2012-02-17 21:05 ` Chandra Seetharaman
2012-02-17 16:09 ` Ben Myers
2012-02-17 19:05 ` Chandra Seetharaman
2012-02-17 19:10 ` Ben Myers
2012-01-23 17:32 ` [RFC v3 PATCH 2/4] xfs: Add pquota fields where gquota is used Chandra Seetharaman
2012-01-31 21:41 ` [NOTES] " Phil White
2012-01-23 17:32 ` [RFC v3 PATCH 3/4] xfs: Add pquotaino to on-disk super block Chandra Seetharaman
2012-01-31 21:42 ` [NOTES] " Phil White
2012-01-23 17:32 ` [RFC v3 PATCH 4/4] xfs: Add a new field to fs_quota_stat to get pquota information Chandra Seetharaman
2012-01-31 21:42 ` [NOTES] " Phil White
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=20120217183902.GE7762@sgi.com \
--to=bpm@sgi.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