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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
