Date:        Thu, 8 Mar 2001 18:19:01 +0100 (MET)
    From:        Hubert Feyrer <hubert.feyrer@informatik.fh-regensburg.de>
    Message-ID:  <Pine.GSO.4.21.0103081816040.8625-100000@rfhpc8320.fh-regensburg.de>

  | while at the subject: does anyone have numbers on QUOTA support
  | enabled/disabled? I wonder if it makes a difference...

I assume you mean the performance impact - measurements on that were
done, but a long time ago now.   There are two impacts to consider,
first the performance on reads/writes/ (etc), for files where there is
no quota, and for files where there is.   The first of those is so small
it is unmeasureable (ie: the cost of having quotas in the system, and
not using them, as far as performance of individual operations goes, is
in the noise where the impact can't be reliably detected).  When there
are limits to be applied, it is possible to measure the impact, but you
never notice it (that is, if you were looking for something to optimise to
make the system faster, quotas wouldn't be it).

Note, when quotas were first implemented, it was done on a vax780 that
typically had about 50 people connected and running code - anything that
used any CPU time that could be detected would have been unthinkable.

I no longer have any of the numbers, it was all way too long ago, but
those were the days when keeping ahead of VMS was actually important,
and everything was run under gprof to test it....

The second impact is much harder to measure, and I don't know of anything
that was ever done in this area - that's what effect the larger kernel
(both the quota code, and the quota data structures for filesystems that
have them) has on overall performance.   That's real hard to quantify
in any reasonable way, other than judging from the general feel of the
system with and without.

  | Which benchmark would one measure that - i understand bonnie is out of
  | question. 

There were some common tests at CSRG they used for this kind of testing,
though what they were I no longer recall.  Personally I just used "normal
work" on the system, which at the time was heavy enough, and roughly
consistent enough, to give reliable results - that is, just running the
system with quotas enabled for a day, measuring how much time was spent
handling the quota stuff (including how much I/O was generated for qouta
activities).  The numbers were always small enough to not be a worry.

kre