A big file created in /tmp can have fatal consequences.
While testing disk performance I have encountered what appears to be a
vulnerability/limitation/unexpected result.
The test was done on oi_147, but is likely to be the same on all nv releases,
and possibly in Solaris as well.
Test Scenario:
Make a big file in /tmp
/usr/gnu/bin/dd if=/dev/zero of=/tmp/1 bs=1k count=500000
this size is fine, producing 512Mb file
increasing the count to 5000000 results in an unresponsive system that never
recovers.
On a different server with 8Gb of memory, it is ok at 5000000 (5Gb) but fails
at 50000000 (50Gb).
The rpool disk has at least twice the free space required.
The issue does not occur when writing the same file outside /tmp.
It doesn't immediately freeze, and leaves no clue as to a root cause on the
console or in logs.
My explanation:
/tmp is mounted in rpool/swap by default.
In theory, since rpool/swap is a zfs file system, it should be able to grow to
the maximum
free space of rpool, but maybe not ?
rpool/swap Used 2.13G Avail 173G Refer 124M Mountpoint -
df -h /tmp shows otherwise.
Filesystem Size Used Avail Use% Mounted on
swap 2.2G 0 2.2G 0% /tmp
Mark.
--
This message posted from opensolaris.org
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
