des at des.no
Fri Jan 4 04:45:38 PST 2008
"Igor Mozolevsky" <igor at hybrid-lab.co.uk> writes:
> 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
> [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.
Dag-Erling Smørgrav - des at des.no
More information about the freebsd-current