The following header lines retained to effect attribution:
>Date: Fri, 16 Jan 2004 06:40:36 -0800
>From: Rich Haney
>Subject: Re: Problem with quota on IRIX xfs filesystem
>To: info-iris-misc@ARL.ARMY.MIL


>Perhaps I should rephrase my issue.


>In the example below, the user has 12 K of available space. Why
>should a simple file creation fail with EDQUOT?


>bash$ quota -v
>Disk quotas for XXXXXX (uid XXXXX):
>Filesystem usage quota limit timeleft files quota limit
> timeleft
>/u 191400 0 191412 1558 0 0
>bash$ touch foo
>Cannot create foo: Disc quota exceeded


>The filesystem has a 4096-byte minimum, but quota is reporting ample
>space. Why is this failing? Am I missing an important piece of this
>puzzle?


>Thanks,
>Rich


# # ###
## # #### ###
# # # # # ###
# # # # # #
# # # # #
# ## # # ###
# # #### ###

An excerpt from /usr/include/sys/quota.h

__uint64_t d_blk_hardlimit;/* absolute limit on disk blks */
__uint64_t d_blk_softlimit;/* preferred limit on disk blks */
__uint64_t d_ino_hardlimit;/* maximum # allocated inodes */
__uint64_t d_ino_softlimit;/* preferred inode limit */

There are two separate limit concerns involved in disk quotas: data space
and inodes. Each of these concerns has both a soft and a hard limit. A
soft limit can be exceeded temporarily (if the softlimit has been exceeded,
then the time left field contains when the temporary period expires). A
hard limit is just that; when it is reached, then an attempt to increase
consumption (in that file system) meets with kernel generated I/O errors.

By your own documention above, the user is already over the soft limit on
data space ( 191400 > 0, by `usage'), almost at the hard limit on data space
( 191400 ~~ 191412 ) and is over both the soft and hard limits on inodes
(called files in the report, but the limit is actually inodes which
includes but is not limited to files, directories, named sockets, named
pipes and symbolic links) both of which are 0 (by files).

Since the user is over a hard limit for the filesystem, the answer is that
the user can not create the file.

(R)ead (T)he (F)ine (M)anual.

I suggest either removing the user from the file system or setting the
quotas in a reasonable manner.

Randolph J. Herber, herber@fnal.gov, +1 630 840 2966, CD/CDFTF PK-149F,
Mail Stop 318, Fermilab, Kirk & Pine Rds., PO Box 500, Batavia, IL 60510-0500,
USA. (Speaking for myself and not for US, US DOE, FNAL nor URA.) (Product,
trade, or service marks herein belong to their respective owners.)