Abusing Solaris attempt #2: stressing out ZFS, PART1
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
March 12th, 2008 at 4:14 pm
what?
March 12th, 2008 at 4:14 pm
i absolutely understand waht the problem here is…
March 15th, 2008 at 6:12 pm
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.
March 19th, 2008 at 11:52 am
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.
March 20th, 2008 at 8:06 pm
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)