Capturing the status of multiple commands in a pipe is pretty tricky…the best way I’ve found is to save the PIPESTATUS array into another array as follows:
declare STAT=(${PIPESTATUS[@]})
…and then you can “process” the contents of “STAT” at your leisure
My Mythbuntu frontend box was making too much noise so I decided to switch it to PXE-boot so I could at least remove the disk noise. Additionally, I wanted to consolidate my storage into a sort of “poor-man’s SAN” attached to my primary network server (the same one hosting this website)…because it’s cool 
.
I weighed the options, and iSCSI seems to be the best supported, and it’s directly supported for the root filesystem in Mythbuntu 9.10…so that’s where I started.
1. I removed the disk from my Mythbuntu frontend and installed it in my primary network server.
2. I installed iscsitarget on my network server…the configuration is in /etc/ietd.conf, and it’s ridiculously simple:
Target iqn.<date>.<reversed FQDN>:<unique name> Lun 0 Path=<block_device>,Type=blockio
3. I did a fresh installation of Mythbuntu 9.10 (Karmic Koala) on my frontend and chose to install to the iSCSI target I setup previously.
4. I copied the kernel to my (Linux) router’s tftpboot directory, and setup a configuration for my frontend box.
5. I had to solve a few technical details around the initramfs and configuring the kernel.
a. The initramfs generated by default doesn’t seem to know about iSCSI, so you must manually configure it and regenerate the initramfs. To do that, complete the iscsi initramfs configuration at /etc/iscsi/iscsi.initramfs and regenerate the initramfs:
cat << EOF > /etc/iscsi/iscsi.initramfs ISCSI_INITIATOR=ISCSI_TARGET_NAME= ISCSI_TARGET_IP= EOF update-initramfs -ck all
b. then I had to figure out the proper syntax for setting the IP address on the kernel command line…which is documented in nfsroot.txt (go figure) in the section covering the “ip=” parameter.
In the end, it works beautifully! No more disk noise from my frontend, and I think my fans are even running quieter because they don’t have as much heat to dissipate. Also, my storage is now consolidated into one gigantic LVM volume group I can slice up any way I like.
So, I was looking around for some comparisons of the various free software options for block-level network based storage (i.e. SAN). Four options came to mind:
1. iSCSI (iSCSI Enterprise Target / open-iscsi initiator)
2. HyperSCSI
3. AoE (vblade “target” / aoetools “initiator”)
4. GNBD
Unfortunately, nobody seems to have put together a useful comparison of these options, so I thought I’d pitch in… Here are my summary conclusions:
1. iSCSI is amazingly well supported. It seems most distributions support it out of the box, and many natively support using it for root.
2. HyperSCSI seems to have stopped development in 2003, and doesn’t seem to be supported by any distributions.
3. AoE is not directly supported by RedHat Enterprise Linux 5 (which is somewhat important to me), but promises better performance than iSCSI at the expense of the flexibility of IP routing (i.e., it’s only possible within one broadcast domain…which means one subnet). Additionally, it’s conceptually very similar to HyperSCSI, and benefits from the the relative simplicity of ATA when compared to SCSI).
4. GNBD has the advantage of built-in fencing (for clusters)…but that can be accomplished in other ways, and it has been surpassed by iSCSI for all other applications. Even the RedHat GNBD FAQ says “…there isn’t much active development of GNBD and iSCSI has an active community of developers, if iSCSI isn’t already faster than it, it eventually will be.”