phaqphaq

Here’s a list of my favorite Firefox plugins:

• Download Statusbar 
• Aging Tabs
• ShowIP
• ASnumber
• FireFTP

No big list after all, but essentially all I need.

Bootable “El Torito” CD-ROMs usually use a boot loader such as isolinux. The loader will allow to boot any particular disk image located inside the iso9660 filesystem.

This makes it very easy to change a particular boot image. It’s merely a matter of picking the right file, changing it and burning a new CD-ROM.

Now there are also CD-ROMs which do not rely upon a boot loader or images inside the iso9660 filesystem.
Instead, the bootable image is stored within the first sectors of the CD-ROM, referenced only from the boot catalog by it’s sector offset. This actually means, that the boot image is hidden and neither visible from the iso9660 filesystem nor loaded from there.

This drawing should get you the basic idea (have a look at the El Torito Specification for further Details):

               +-------------------------+
    Sector 0:  |          SYSTEM         |
               |-------------------------|
    Sector 16: |      Primary Volume     |
               |-------------------------|
    Sector 17: |    Boot Record Volume   |-------+
               |-------------------------|       |
               |                         |       |
               |-------------------------|       |
               | Set Termination Volume  |       |
               |-------------------------|       |
               |     Boot Catalog        | <-----+
               |                         |-------+
               |-------------------------|       |
               |  Bootable Disk/Loader   | <-----+
               |-------------------------|
               |   CD-ROM File System    |
               +-------------------------+

So to change the boot image, it needs to be extracted from the CD-ROM first.

This is where geteltorito comes in, a perl utility by Rainer Krienke, which serves exactly this purpose.

Luckily enough I found this one before I started writing an image dumper on my own…

Back in January I introduced an upcoming series about FreeBSD software RAID implementations and how they compare to each other.
I know it’s been some time since, but I was kept busy on some other stuff which prevented me in polishing up the results. My appologies for the delay.

Now, in this article I’m going to talk about FreeBSD’s gvinum and gmirror for disk mirroring (aka RAID1).
The benchmark results shown below will illustrate the difference between these two implementations. To get a better idea of their real meaning, I’m providing you with the single disk results as well.

Now as far as software RAID goes in FreeBSD, gvinum (geom vinum) is not gmirror (geom mirror). They basically do the same, but in a slightly different manner.

gmirror does a direct approach in mirroring. It works with the low level device (the geom provider) directly to create the resulting mirror (the geom consumer). It is very specialized in this and supports also different balance algorithms which do have quiet an influence to performace as you will see later on.

gvinum is all different. geom providers are referred to as subdisks or drives, which in turn are members of plexes, which again form volumes. In fact gvinum is a real volume manager that is capable of doing far more than simple disk mirroring. It supports also RAID0, JBOD and even RAID5. It is however not yet as mature and stable, especially when it comes to RAID5 – but this is a different story.

# rawio benchmark results

rawio was choosen to measure I/O speed during concurrent access. rawio was set to run all tests (random read, seq read, random write, seq write) with eight processes on the /dev/mirror/* and /dev/gvinum/* devices.

Results for the single disk are provided as well to compare performance not only between the different frameworks but also against the native disk performance.

Click the images to see the actual result values and a chart.

* WPG2 Plugin Not Validated *

* WPG2 Plugin Not Validated *

# dd benchmark results

dd was choosen to measure raw block access to /dev/mirror/* and /dev/gvinum/* devices. dd was set to run sequential read and write tests using block sizes from 16k to 1024k.

Click the images to see the actual result values and a chart.

* WPG2 Plugin Not Validated *

* WPG2 Plugin Not Validated *

# bonnie++ benchmark results

finally, bonnie++ was used get pure file system performance.

Click the images to see the actual result values and a chart.

* WPG2 Plugin Not Validated *

* WPG2 Plugin Not Validated *

# conclusion

Looking at raw disk access I must conclude that none of the frameworks beats single disk performance in overall when it comes to blockwise input with dd. One get’s however quiet an impression about the overhead imposed by both gvinum and gmirror.

Now since ‘dd’ is very synthetic by it’s nature, rawio is much better to see how the devices would perform under a more “real-life” situation.
Winners are both gvinum (mirrored plex) and gmirror (round-robin balance algorithm), while the later is still a bit faster though.
Although rawio benchmark results may look low, these numbers where achieved by running 8 processes at once. They’ll reflect best what could be expected in a true multi-user environment with concurrent access.

Finally for bonnie++ we see some interesting results. Performance is almost identical for all implementations expect for block write access, where the single disk is the unbeaten winner.
One must keep in mind that the first six tests performed by bonnie++ (rand delete/read/create, seq delete/read/create) are limited by I/O performance of both the system bus and the device itself. The hardware I used for testing was capable of about 160 – 170 I/Os per second. I admit that results could be different if the tests are re-run on decent hardware with a higher I/O throughput. It’s possible that modern hardware reveals an I/O barrier for abstracted devices which cannot be seen from my tests.

Personally I prefer using gmirror over gvinum because of it’s more simplistic configuration approach. In terms of performance, gvinum is almost as good as gmirror (round-robin algorithm) but still can’t yet keep up with it.
While both may look slower altogether in synthetic tests (dd and bonnie++) than the other balancing algorithms, rawio reveals their potential in a manner which is comparable to real field duty.

The next article will discuss gvinum and gstripe for RAID0.