hi Brian,
On Sat, Jan 05, 2002 at 09:23:14PM -0600, Brian Johnson wrote:
>
> This behavior is different from ext2/ext3. In ext2/3 the data does not
> need to be written to disk to be reflected in the quota. I have tested
> this and my output is below. I watched vmstat and xfs showed the correct
> block quota only after the 1024 kbytes where written to disk while ext2/3
> showed it right after dd was run but before it was written to disk. It
> seems that in XFS repquota show only what was written to disk and ext2/3
> shows what was is on the disk plus what is in the buffer so the block
> quota number is never out of date.
>
> ext2 (I think I remember testing this with ext3 and it was the same):
>
For these filesystems, repquota will do a Q_SYNC (quotactl(2)) before
attempting to fetch all of the dquots off the disk. XFS implements
this same functionality but quite differently (without sync operations).
>
> XFS:
>
> Here repquota shows the block change only after the data is written to
> disk.
>
Not quite - we will only read off the disk if we do not have the
dquot incore already. In this case though we're guaranteed to
have it in memory because we just created a file as that user.
> # /usr/sbin/repquota /users | egrep "^root" ;\
> > dd count=1024 bs=1024 if=/dev/zero of=writetest ;\
> > /usr/sbin/repquota /users | egrep "^root" ;\
> > sleep 30 ;\
> > /usr/sbin/repquota /users | egrep "^root" ;\
> > sleep 10 ;\
> > /usr/sbin/repquota /users | egrep "^root"
> root -- 7200 0 0 20 0 0
^^^^^^ ^^^^
> 1024+0 records in
> 1024+0 records out
> root -- 7200 0 0 21 0 0
^^^^^^ ^^^^
I suspect what you're seeing here is the effects of delayed
allocation. We can see above that the inode count has been
incremented, so we are indeed getting the updated dquot (ie.
we're not reading something "old" off the disk - we're not
reading off the disk at all in fact).
Since space is not allocated for the data until later, the
used space for the file is not updated until then (we don't
actually know how much space to charge the user until space
allocation is done - which sounds counter-intuitive but is
quite correct).
> root -- 7200 0 0 21 0 0
> root -- 8224 0 0 21 0 0
^^^^^^ ^^^^
>
> So it seems ext2 shows not what is on disk, but what the user has written
> and may be in the buffer and XFS just shows what is on the disk.
Not really, in fact its more like the other way around just to
confuse the matter more. XFS has no Q_SYNC quotactl command, as
dquots are journaled along with the associated inode, freespace,
superblock,... change (ie. Q_SYNC would == sync(2)), but other
filesystems quota use Q_SYNC to get a recent snapshot of the quota
file out to disk, and then read off disk - XFS doesn't work that
way.
[40 seconds does seem excessive to me though, I'm not 100% sure
why it takes quite that long. The /proc/sys/vm/pagebuf params
might need some tuning here? (i'm guessing). Ask me in a month
or so - I have my head buried in pagebuf code at the moment, so
I might know the answer then. ;-)]
cheers.
--
Nathan
|