hi John,
On Nov 20, 1:01am, John M Trostel wrote:
> Subject: Using quotas with Linux XFS
> ...
> 2. If I set the block and file limits for a user to some non-zero number
> such that repquotas responds:
>
> [root@jtsdell quota]# /usr/local/sbin/repquota /dev/hda8
>
> Electric Fence 2.0.5 Copyright (C) 1987-1998 Bruce Perens.
> Block limits File limits
> user used soft hard grace used soft hard grace
> root -- 16 0 0 8 0 0
> jt -- 45856 0 0 12 0 0
> sambaman -- 8 104 104 1 50 50
>
> The setting of the quota seems to have worked BUT... sambaman can not
> change anything or add anything to the filesystem without a disk quota
> exceeded error.
>
ok, I think I can explain this one now. the soft/hard blocks
reported above is in basic blocks (512), not filesystem blocks
(probably 4096), so your number should be divided by 8 to start
with (i.e. the hard limit is 13 filesystem blocks). I need to
fix the way this is reported (in the user tools) and also the
set mechanisms (edquota/setquota).
depending on what you were doing, it is quite likely that you
really were exceeding that each time.
should also note that quota are enforced based on the maximum
number of blocks required by a transaction (which can be quite
a few blocks) and even though the end result might end up using
fewer blocks than anticipated you will not be allowed to proceed
if you have insufficient space to do the initial (maximum) space
reservation.
e.g. even creating an empty file can result in a change in form
of the parent directory (shortform/block/btree) and if one of
these transitions happen, many more blocks than one might think
are needed (some space is needed anyway for the new inode creat).
I've verified using some extra debugging code that using a
larger number of blocks to give you some initial headroom, and
then consuming space till you reach that, does actually work.
the inode limit enforcement is obviously much simpler, and that
also seems to work.
I've fixed your "usrquota" problem. "grpquota" is a whole other
can of worms, so don't go there yet. Dunno about your grace
problem yet - will require some further digging.
cheers.
--
Nathan
|