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

Reply via email to