ulimit

[Mats Wichmann]

In article <17042 at mimsy.UUCP>, chris at mimsy.UUCP (Chris Torek) writes:
> The mistake is not the existence of ulimit (although there are those
> who would argue this as well).  The mistake is that the default limit
> is set to such a tiny value.  If the default limit were, say, 100
> exabytes,% it would not be such a problem.
> 
> The default file size limit should be `unlimited'; sysadmins should
> be able to raise and lower it, and users should be able to lower it.
> 
> -----
> % This is not `100 8mm tape drives': `exa' is a metric unit.  If I have
>   not got them backwards, the order is kilo, mega, giga, tera, peta,
>   exa.  (In the other direction we have milli, micro, nano, pico,
>   femto, atto.  These are abbreviated as k/M/G/T/P/E and m/u/n/p/f/a
>   respectively.  And `b' is bits; `B' is bytes; `mb' is millibits.
>   But I see my footnote has digressed.)
> -- 
> In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
> Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris

(Nice digression. A little education never hurts...)

No problem? Just had to toss my own horror story into the ring: 
just a few weeks ago I brought up a new version of NFS, and found that 
clients didn't write to the old servers too good any more. Turns out this
nifty little bit of code was responsible:

	if (u.u_offset >= (u.u_limit << SCTRSHFT))
		/* don't write because you exceeded the ulimit, right? */

Now let's see. If SCTRSHFT is 10 (like on our system), 
(100 exabytes << SCTRSHFT) is what?  What does come after exa? 
Or do we spell it "0" because my ints aren't that big?

Needless to say, the above cited code is now a bit different...

-Mats Wichmann
-Acer Counterpoint, Inc.