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):
Here repquota shows the correct block change before the data is written to
disk.
# /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 -- 4238746 0 0 129504 0 0
1024+0 records in
1024+0 records out
root -- 4239775 0 0 129505 0 0
<< "vmstat 1" output with this line that shows write to disk occured here in
time
r b w swpd free buff cache si so bi bo in cs us sy
id
0 0 0 64012 18344 260140 152864 0 0 0 1049 112 20 0 6
94
>>
root -- 4239775 0 0 129505 0 0
root -- 4239775 0 0 129505 0 0
XFS:
Here repquota shows the block change only after the data is written to
disk.
# /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
root -- 7200 0 0 21 0 0
<< "vmstat 1" output with this line that shows write to disk occured here in
time
r b w swpd free buff cache si so bi bo in cs us sy id
0 0 0 21516 2904 0 10168 0 0 0 1024 114 14 2 8 90
>>
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.
It looks like XFS knows about the number of block written because if it
says I have 10000 kbytes free and I have just written 9000 kbytes that has
not been written to disk and I try to write another 9000 kbytes (because
repquota shows I have 10000 kB free) the file will be cut off at 1000 kB.
So XFS seems to know the blocks witten by the user (not just what is on
the disk) but repquota is reporting something else.
Brian
On Fri, 4 Jan 2002, Mike Burger wrote:
> To me, this makes perfect sense. You can't really get the used block
> count to change until the blocks have actually been written, and teh
> allocation tables written along with them.
>
> It seems to me, and I'm not involved in any way with the development
> project, that you'd be asking for a lot of trouble to try to update part
> of the allocation table without actually having had the data written to
> disk.
>
> On Fri, 4 Jan 2002, Brian Johnson wrote:
>
> > I noticed the block usage amount repquota reports is out of date for about
> > 40 sec after a file is written or until sync is run.
> >
> > For example,
> > # /usr/sbin/repquota /users | grep root ;\
> > dd count=1024 bs=1024 if=/dev/zero of=writetest ;\
> > /usr/sbin/repquota /users | grep root ;\
> > sleep 30 ;\
> > /usr/sbin/repquota /users | grep root ;\
> > sleep 10 ;\
> > /usr/sbin/repquota /users | grep root
> >
> > Produces:
> >
> > root -- 6176 0 0 19 0 0
> > 1024+0 records in
> > 1024+0 records out
> > root -- 6176 0 0 20 0 0
> > root -- 6176 0 0 20 0 0
> > root -- 7200 0 0 20 0 0
> >
> >
> > Running sync after the write gives up to date usage data:
> >
> > # /usr/sbin/repquota /users | grep root ;\
> > dd count=1024 bs=1024 if=/dev/zero of=writetest2 ;\
> > sync ;\
> > /usr/sbin/repquota /users | grep root
> >
> > root -- 7200 0 0 20 0 0
> > 1024+0 records in
> > 1024+0 records out
> > root -- 8224 0 0 21 0 0
> >
> >
> > Is there a way to get the number of used blocks that is not out of date? I
> > am running kernel 2.4.17 from CVS and also have tested this on the 1.0.2a
> > release.
> >
> > Thanks,
> > Brian
> >
> >
>
>
|