X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id q0VL1ELu100004 for ; Tue, 31 Jan 2012 15:01:14 -0600 X-ASG-Debug-ID: 1328043672-04cb6c225e37a910001-NocioJ Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by cuda.sgi.com with ESMTP id lfG3lGd0jqu9JQcD for ; Tue, 31 Jan 2012 13:01:12 -0800 (PST) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.129 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADhUKE95LD+b/2dsb2JhbABCrmWBBoFyAQEFJwsBIxUOEAgDDgouFCUDIRPBBBOIF4JnAQQDAg0CBwcEBgELAQgFAwMJBgQPhCQBAwEEHoM5BJUfiS+JOg Received: from ppp121-44-63-155.lns20.syd6.internode.on.net (HELO dastard) ([121.44.63.155]) by ipmail06.adl2.internode.on.net with ESMTP; 01 Feb 2012 07:31:11 +1030 Received: from dave by dastard with local (Exim 4.76) (envelope-from ) id 1RsKpC-0006vf-Kl; Wed, 01 Feb 2012 08:01:10 +1100 Date: Wed, 1 Feb 2012 08:01:10 +1100 From: Dave Chinner To: Ben Myers Cc: Christoph Hellwig , Nathan Scott , xfs@oss.sgi.com Subject: Re: [PATCH] xfs_quota: remove calls to XFS_QSYNC Message-ID: <20120131210110.GN9090@dastard> X-ASG-Orig-Subj: Re: [PATCH] xfs_quota: remove calls to XFS_QSYNC References: <20120130115024.GA884@infradead.org> <20120131162617.GF7762@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120131162617.GF7762@sgi.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail06.adl2.internode.on.net[150.101.137.129] X-Barracuda-Start-Time: 1328043672 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.87232 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 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 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