Re: Problem with quota on IRIX xfs filesystem - SGI

This is a discussion on Re: Problem with quota on IRIX xfs filesystem - SGI ; Randolph J. Herber wrote: >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 ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: Problem with quota on IRIX xfs filesystem

  1. Re: Problem with quota on IRIX xfs filesystem

    Randolph J. Herber wrote:

    >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.
    >

    -SNIP-


    Thanks for the reply, Randolph. Despite the fact that your answer is
    reasonable - and I would agree with it - what I'm seeing in reality
    doesn't seem to agree with it.

    The user in the example was just for illustration - I manually
    manipulated the quotas to test it. Basically, I need to avoid a
    situation where and end-user is incorrectly denied access to file
    creation because of a quota issue. End-users will be greatly concerned
    if, for example, they can't receive mail because of quota, when it
    appears to them that they have available space. Users that are
    legitimately over quota should be denied this access, of course.

    So, with the example user, I updated the quotas, setting a soft limit
    and the appropriate inode limits. The account is within all of the limits:


    bash$ quota -v
    Disk quotas for XXXXXX (uid XXXXX):
    Filesystem usage quota limit timeleft files quota
    limit timeleft
    /u 191880 192000 192000 1566 5000 5000
    bash$ touch foo
    Cannot create foo: Disc quota exceeded


    As you can see, the usage is < either the soft OR the hard limit (by
    120K), and the inode count is below both the soft and hard limits. But
    it continues to fail. If I bump the limit up an additional 8K, it works
    fine:


    bash$ quota -v
    Disk quotas for XXXXXX (uid XXXXX):
    Filesystem usage quota limit timeleft files quota
    limit timeleft
    /u 191880 192008 192008 1566 0 0
    bash$ touch foo
    bash$


    Note that this seemed to be independent of the inode quotas - whether or
    not I set them, I could not create the file with < 128K of available space.

    For anyone interested, here's the mtab entry for the filesystem:

    /dev/xlv/stripe0 /u xfs rw,raw=/dev/rxlv/stripe0,quota 0 0



    --
    Rich Haney
    rich@haneys.net



  2. Re: Problem with quota on IRIX xfs filesystem

    Rich Haney wrote in message news:...
    > Randolph J. Herber wrote:
    >
    >
    > bash$ quota -v
    > Disk quotas for XXXXXX (uid XXXXX):
    > Filesystem usage quota limit timeleft files quota
    > limit timeleft
    > /u 191880 192000 192000 1566 5000 5000
    > bash$ touch foo
    > Cannot create foo: Disc quota exceeded
    >
    >
    > As you can see, the usage is < either the soft OR the hard limit (by
    > 120K), and the inode count is below both the soft and hard limits. But
    > it continues to fail. If I bump the limit up an additional 8K, it works
    > fine:
    >
    >
    > bash$ quota -v
    > Disk quotas for XXXXXX (uid XXXXX):
    > Filesystem usage quota limit timeleft files quota
    > limit timeleft
    > /u 191880 192008 192008 1566 0 0
    > bash$ touch foo
    > bash$
    >
    >
    > Note that this seemed to be independent of the inode quotas - whether or
    > not I set them, I could not create the file with < 128K of available space.
    >
    > For anyone interested, here's the mtab entry for the filesystem:
    >
    > /dev/xlv/stripe0 /u xfs rw,raw=/dev/rxlv/stripe0,quota 0 0



    I think your problem is a feature of the xfs filesystem -
    preallocation of disk space for files opened for writing. If you
    open, lseek and write a new file per your previous example:

    #include
    #include
    #include
    #include
    int main (void)
    {
    int fd, pos;
    fd=open("/var/tmp/testfile", O_WRONLY | O_CREAT , 0600);
    lseek(fd,500,SEEK_END);
    pos = write(fd,'K',1);
    sleep (10);
    close (fd);
    sleep (10);
    exit (0);
    }

    du will (probably) report 128 blocks for /var/tmp/testfile before
    close() is called, then 8 blocks afterwards.

    You can change this behaviour using the O_SYNC flag in the open()
    call.

    Hope this helps,

    Andy

+ Reply to Thread