"Igor Mozolevsky" <igor@hybrid-lab.co.uk> writes:
quoted text
> Broadcasting SIGDANGER would be a much better option; followed by
> SIGTERM to the memory hogger (to allow for graceful termination) and
> only then SIGKILL. I can imagine a few (legitimate) scenarios when a
> user process would want to hog as much RAM as possible...

We don't currently have SIGDANGER, but the signal code was rewritten
years ago to allow more than 32 signals precisely for the purpose of
implementing an AIX-like SIGDANGER.  This wasn't done, however, and
eventually SIGTHR was the first new signal to take advantage of the
rewritten code.

quoted text
> [about pre-zeroing a backing file]
> Surely you can just fseek() on the file at the correct lenght?

No.  First of all, you're thinking of lseek(), not fseek() Second, an
lseek() beyond the end of a file will not actually extend the file.
Third, ftruncate() (which *will* extend a file if it is shorter than the
requested length) or lseek() followed by write() will not allocate
physical disk space except for the data actually written; it will create
a sparse file, which when later written to will become fragmented,
resulting in horrible performance.

DES
-- 
Dag-Erling Smørgrav - des@des.no
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"