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