From: Dave Chinner <david@fromorbit.com>
To: Ben Myers <bpm@sgi.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Nathan Scott <nathans@debian.org>,
xfs@oss.sgi.com
Subject: Re: [PATCH] xfs_quota: remove calls to XFS_QSYNC
Date: Wed, 1 Feb 2012 08:01:10 +1100 [thread overview]
Message-ID: <20120131210110.GN9090@dastard> (raw)
In-Reply-To: <20120131162617.GF7762@sgi.com>
On Tue, Jan 31, 2012 at 10:26:17AM -0600, Ben Myers wrote:
> On Tue, Jan 31, 2012 at 06:57:04AM +1100, Nathan Scott wrote:
> > On 30 January 2012 22:50, Christoph Hellwig <hch@infradead.org> wrote:
> > > ...
> > > Nathan, I've cced you in case you still remember anything about this,
> > > although it's fairly unlikely after 6.5 years. Also if anyone at SGI
> > > can find anything about the above commits in BugWorks additional feedback
> > > would be welcome.
> >
> > I can't recall - but usually there was greater detail in the bugworks entry,
> > I think thats your best source now.
> >
> > Patch looks OK to me FWIW, assuming nothing comes of the bugworks
> > archeology exercise.
>
> I'm not a ptools expert so I had to ask around. This turned out to be
>
> PV942815 - XFS quota reporting interacts badly with delalloc
>
> "We get a constant trickle of confused people who've found that the used
> space reported by repquota/quota does not get immediately updated after
> creating new files / extending existing ones. The problem is a result
> of buffered IO in XFS doing delayed allocation - if we have not done an
> allocation, the quota accounting has not been updated, so we end up with
> effectively stale data being reported.
>
> This affects CXFS too, of course. After discussion a few weeks back on
> the XFS conf. call, it was decided to not change CXFS (too expensive to
> do a flush on all nodes) but that we can make some simple XFS changes to
> make this less of a problem - i.e. flushing delalloc data just before we
> extract quota information." -Nathan
So effectively what that says to me is that quota only exports the
real block usage, even though it internally tracks delalloc
reservations. Perhaps an additionaly change to make in this case is
to fold the reserved blocks into what is reported to the quota
utilities?
Indeed, what is exported to userspace via xfs_qm_export_dquot() is
the information in the dquot core - the on-disk information - so
perhaps all we need to do is export dqp->q_res_bcount (the count of
real + reserved blocks) instead of the on-disk info?
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-01-31 21:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-30 11:50 [PATCH] xfs_quota: remove calls to XFS_QSYNC Christoph Hellwig
2012-01-30 19:57 ` Nathan Scott
2012-01-31 16:26 ` Ben Myers
2012-01-31 21:01 ` Dave Chinner [this message]
2012-02-01 10:24 ` Christoph Hellwig
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=20120131210110.GN9090@dastard \
--to=david@fromorbit.com \
--cc=bpm@sgi.com \
--cc=hch@infradead.org \
--cc=nathans@debian.org \
--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