From: <SP02038%SWTEXAS.BITNET@ricevm1.rice.edu>
Subject:  SR10.4 Disk Quotas Are Total TRASH
X-Original-To:  apollo@engin.umich.edu, SP02038
Organization: Electrotechnical Laboratory, Tsukuba Science City
Distribution: fj
Date: Tue, 15 Sep 1992 19:08:00 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>


Paul Szabo writes "Disk quotas at 10.4: problems":

> I now have a few nodes at SR10.4, so I wanted to try out the fancy new disk
> quota system. I found the following problems with it. In my opinion these
> problems (by themselves or in combination) make the quota system unusable.

You too?  Gee, and I thought I was the only one :)

> 1) There is a limit of 1024 users in the disk quota table. (This limitation
>    is shown by INVOL.) We have well over that many users: some would have to
>    miss out. (It seems that a user without a disk quota entry is equivalent
>    to having a limit of zero.)

Our site only has a few hundred users, so the limit is not a problem.  The docs
do mention that everyone who needs to write to the volume, must have an entry
in the quota table for the volume.

> 2) There is no tool to re-build the 'currently-used' table. It seems to me
>    that the currently-used values only change when files are created/changed
>    (only for users with disk quota entries, and only while quotaon is in
>    effect). Creating a quota entry for a user will always see his
>    currently-used value start at zero.

Actually there is, but not a very convenient one.  Salvol will refresh the
quota table.  Our volumes are in use nearly 24hrs a day, so taking a volume
off-line to refresh the quota table is an inconvenience to the users and
creates a hassle for the administrators.  There needs to be a way to refresh
the quota table without taking the volume off-line (which in the case of our
disked nodes means taking the node down!)

> 3) There is no command to view one's own disk quota limit and usage. The
>    command 'edquota -l' displays the full table; this has implications about
>    the privacy of other users, besides the inconvenience of having to use
>    'grep' on the output.

Whoever designed the apollo's quota system sure wasn't thinking about the users.
Our users do a lot of their work on our VAX systems; hence, they are in the
habit of checking their quota a couple of times a day.  Additionally, the
faculty are not too happy about everyone having the ability to know how much
space they are taking up.  Surely there must be a quick fix to this one.

> 4) There may be no error messages when exceeding quota. In particular, the
>    command 'echo abc > file' would return no error message even though I was
>    over my quota (it created an empty file instead: this does not need any
>    quota). Similarly the command 'echo abc >> file' would silently fail to
>    extend the file. (The commands were run in the /bsd4.3/bin/csh, on a node
>    running 10.4; the file was on another node running 10.4 and disk quotas.)

Now this chaps my hide!  This renders the quota system utterly useless!!!!!
Whoever in HP assumed the quota system was FUNCTIONAL must have been living
on the planet Mars for the last decade.  This utterly infuriates me!  One
of the major reasons for us to upgrade to SR10.4 was because of the problems
we were experiencing due to NOT having disk quotas.  Now we have disk quotas,
but they create more problems than we originally had.

However, I have experimented with the trying to exceed the quota, and have found
that most of the time (NOT ALL) an error message is displayed.  However, I have
a problem with the way the quota violation is handled.  If a new file is being
created when the quota is exceeded, then the file SHOULD fail to be created.  If
the new file would replace an existing file, then the existing file SHOULD be
restored -- since this is probably difficult to implement the existing file
SHOULD at least be deleted.  If the user was appending to a file when the quota
violation occurred, then the previous end of file should be restored -- this
should be pretty easy to implement.  In all cases a quota violation error should
be displayed.

> 5) Files can be 'given away', after which they are counted against the new
>    owner's quota. This defeats the purpose of the system and allows
>    denial-of-service attacks.

Not sure what he means here.

> Does anyone know a way around these problems? (Would HP fix them if I
> submitted an APR?) I hope they can be fixed, I was really looking forward to
> using disk quotas.

This is a MAJOR BUG!!!  I feel ripped off by HP.  I was considering the idea of
purchasing some PA-RISC systems, but HP has treated the Domain/OS customers so
poorly that we'll probably go with DEC.

On a similar note... The PRMGR at SR10.4 is TRASH too.  I have tried everything
conceivable to get it working, but it still cannot find the global location
broker.  The glbd is running, and everything is able to access it without
difficulty EXCEPT the prmgr.  Someone posted something earlier about it, and the
reply was to use the SR10.3 prmgr.  Well, we upgraded from a much earlier SR and
don't happen to have the SR10.3 prmgr.  I would be eternally grateful to anyone
willing to mail me the SR10.3 prmgr as a uuencoded file :)

Shaun Pankau                            e-mail: sp02038@swtexas.bitnet
UNIX Systems Administrator                      sp02038%swt.decnet@relay.the.net
Computer Science Department
Southwest Texas State University
Newsgroups: fj.mail-lists.apollo