Parolski.com

Today we finally moved our computing equipment into a room that has been provided for us by the faculty (BIG THANK YOU TO THE FACULTY TEAM, MIKE PHILIPS AND IAN ROBINSON! ). Its in the Surrey Club, just across the road from the Penryhn road campus:

Hopefully we’ll be getting a network connection soon, its been difficult to find a place on the University network where we can have complete autonomy without breaking anything else!

Theres plenty of room, with about five tables and twice as many chairs, as well as about 14 power sockets in the walls!

Its a bit messy in these shots, maybe we should have taken an after shot! The tables are now lined against the walls, and the beastly Dell servers are under the table to the left behind the door. We were initially rejected by the uni marketing team for compsoc.kingston.ac.uk because we might not represent the views of the uni, much like the case of The River who also applied for a subdomain of kingston, but were denied. However, Ian is going to restate our case, given that we are affiliated to the Student Union and so by default only represent our own views anyway!

Progress!

In my last post, the files were being written to an IDE hard disks. Now lets see what happens if we write to /tmp instead. Will Solaris cope with ten million files in /tmp? First, if we want to make use of the compression, we need to make a file system:

We make the files (we can use files instead of real disks…):

anton@solaris-devx ~ $ mkfile 100M /tmp/file1
anton@solaris-devx ~ $ mkfile 100M /tmp/file2
and then su to root to make the ZFS file system (mirrored):

# zpool create crazedPool mirror /tmp/file1 /tmp/file2

I should note that for some reason ZFS didn’t make use of the entire file size:

# zfs list crazedPool
NAME USED AVAIL REFER MOUNTPOINT
crazedPool 110K 63.4M 20K /crazedPool

And now the real test. How about a big file? Lets say, 100G?:

anton@solaris-devx dir1 $ time mkfile 100G woot
real 1m21.995s
user 0m0.191s
sys 0m30.308s
And what about 10000 files, each 10M in size?:
anton@solaris-devx dir1 $ i="0"
anton@solaris-devx dir1 $ time while [ $i -lt 10000 ]
> do
> mkfile 10M la0$i
> i=$[$i+1]
> done
real 1m46.789s
user 0m4.665s
sys 0m43.492s

So far, so good. So now lets push the envelope off the desk. Or maybe off a cliff. Lets see what happens when we make a 100TB file with ZFS!

anton@solaris-devx dir1 $ ls -l megaFile
-rw------- 1 anton staff 107374182400000 Mar 15 18:05 megaFile

and the compression ratio?:

anton@solaris-devx tmp $ zfs get compressratio crazedPool
NAME PROPERTY VALUE SOURCE
crazedPool compressratio 1.00x -

hmm, not quite what I was expecting!

I’m sure my readers at some time or another have had the pleasure of installing Windows XP. They will also probably had the pleasure of having to wait 3/4 of an hour for it to finish! Well, there is a solution!

Furthering the idea of putting the disk install image in RAM before installing, why not write to a Virtual hard drive, also in RAM (if your using VirtualBox)! Specify /tmp as the prefix to your disks name in the “Virtual Disk Location and Size” dialogue window. The result? An installation of windows that will reboot in about 15 seconds. Of course, this is good for some tasks, but not all! Your millage will vary!

NOTE01: I would recommend your have at least 3GB of RAM before trying this!

NOTE02: If you want to keep the install for good, you will need to copy it off /tmp before you reboot, otherwise your virtual drive will be gone!

I must admit though, it still wont solve any post-install issues!

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

I really do wonder whether or not this was a real advert that went out, or if it was just an office joke. Either way, thumbs up!

You need execute permission on a directory to cd to it! Is read not enough? In practice, no. The chdir system call requires execute permission to make that directory the starting point for path searches. According to the chdir (system call, section 2) man page:

For a directory to become the current directory, a process
must have execute (search) access to the directory.

So when trussing the output of a failed cd to a directory with no execute permissions we see:

chdir("lala") Err#13 EACCES [file_dac_search]
chdir(”lala”) Err#13 EACCES [file_dac_search]

and as the man page goes on to say:

EACCES Search permission is denied for any com-
ponent of the path name.

Reading this article explains, that of course you can’t execute a directory but rather, that the execute permission bit is reused for different purposes. Without execute permission on the directory, you can’t stat() any files within the directory. Opening, deleting and other operations on a file first require you to stat() it first, as stat() gives you the files inode. Without the files inode, theres very little you can do with it!

Armed with this knowledge you might feel inspired to check out the source code of this call for yourself!