So last time we pulled out an IDE hard disk, and Solaris lived. It got me thinking…What else can we do to a hard disk that Solaris might not like? What about making a really big file? What about a 9TB file on an 80GB hard disk?:
anton@solaris-devx ~ $ time mkfile 9000G deleteThis
real 120m42.953s
user 0m16.448s
sys 46m55.092s
anton@solaris-devx ~ $ ls -l deleteThis
-rw------- 1 anton staff 9663676416000 Mar 9 02:22 deleteThis
And the machine didn’t die! But what about the compression ratio?
anton@solaris-devx ~ $ zfs get compressratio tank/home
NAME PROPERTY VALUE SOURCE
tank/home compressratio 1.22x
Looks like the ratio is an average for all the files on that file system. So lets try to artificially inflate this value. We can run a little script like this:
#/bin/sh
#A little script to make ten million files each 1 megabyte in size
i="0"
while [ $i -lt 10000000 ]
do
mkfile 10M la$i
i=$[$i+1]
done
The result (after about an hour of making files) wasn’t good:
bash: fork: Not enough space
This looks more like an issue bash had rather than ZFS. So did we push up that compression ratio?:
anton@solaris-devx mess $ zfs get compressratio tank/home
NAME PROPERTY VALUE SOURCE
tank/home compressratio 1.22x -
Seemingly not. To compensate, we’ll do something more crazy for PART2
Tags: hard drive, solaris, stress, zfs
what?
i absolutely understand waht the problem here is…
My preferred method for confusing Solaris is to change the order of the boot disks in the BIOS and then edit live upgrade files by hand. As well as move zfs pools around between installs without exporting correctly - as of yet I have failed to kill my ZFS pool despite copious abuse - /tank has so far been a rather apt name for it.
here is another test.
http://uadmin.blogspot.com/2005/11/zfs-spoils-prank.html
turns out that zfs teats strings of 0’s as a “hole” in the file and doesn’t use any space to store the hole or very little anyway.
not sure why you are not getting any improvement in your compression ratio i see 2.0x frequently in text files.
The compression ratio didnt improve because no compression was succesfully applied! The file only consisted of those “holes” (i.e. all the block pointers for it were null) and so the files actually consumed no space!!! (As per Jeff Bonwick’s explanation here):
http://www.parolski.com/2008/03/15/abusing-solaris-attempt-2-stressing-out-zfs-part2/#comments)