Wednesday, September 28, 2011

iPhone Battery Drain, revisited

It happened again. I earlier blogged about the situation where my iPhone started eating the battery so fast that it was actually hot to the touch. Again, the issue was near-continuous network access to my home Exchange server (over ActiveSync), but this time I was able to resolve the issue by disabling calendar sync (which deleted all the calendar entries for that connection) instead of deleting the whole profile.
As soon as the calendar stopped being sync'd, the high network utilization went away; re-enabling the sync brought back the calendar items without causing the utilization problem.

Friday, September 16, 2011

iomega ix2-200 NAS non-cloud to cloud upgrade

UPDATE: DO NOT attempt to adapt this process to update an ix4 to the cloud-OS version!
If you do so, the upgrade will apparently attempt to update the BIOS of the ix4, and there appears to be a sufficient difference between the two products (cloud, non-cloud) that you will end up "bricking" your ix4. This happened to me (yes, I know I was taking a big chance) and someone else I know. Having a complete set of pristine, factory-reset drives will not give you the ability to revert to the non-cloud OS if you have a problem with the upgrade.
For the record, the system I started with had a sticker on the flash chip indicating that it was running the "V1.0.7" code.
The only known fix is a "low-level format" back at iomega support.

Standing on the shoulders of others...

So you've got a "non-cloud" version of the iomega ix2-200, and you're miffed that iomega doesn't officially support an upgrade path to convert it to the newer "cloud" editions. Maybe you want some of those cloud features, or maybe you have a Mac with Lion, which apparently isn't supported on the non-cloud models.
The upgrade can be accomplished; however it is destructive. You will not be able to perform an in-place upgrade with this technique, although you will be able to "get back" to having the original equipment—if that's what you desire.

What follows is a recipe that worked for me; your mileage may vary.

Required Hardware:
  • iomega ix2-200 (duh!)
  • Blank, FAT32-formatted USB thumbdrive with a drive activity light, 2GB or larger.
  • pin, toothpick or other small, stiff wire that can be used to press and hold the reset button on the ix2 for ~90 seconds.
Optional Hardware:
  • New hard drives. This is a prime opportunity to upgrade a 1TB or 2TB (raw) model to a 4TB or 6TB unit; it also gives you a fallback position in the event you brick the thing while working with the new drives. If you go this route, however, do not try to improve performance by switching to 7200RPM drives: The heat output of those drives is too high for the tiny fan in the chassis to handle. Stick with "green", variable RPM drives, and you should be okay.
  • USB-to-SATA adapter. This eliminates the need to crack the case of a desktop machine (for access to the SATA ports) to clear a drive that will be re-used for the conversion.
Required Software:
  • Linux distribution with openssh, tar, md5sum, gunzip and the ability to mount files to a loopback device. Believe it or not, your ix2 itself will fit the bill if you don't otherwise have a linux distro handy; all you need is SSH access, and you're golden. This recipe assumes the use of the ix2.
  • Latest/greatest upgrade of the ix2-200 "cloud edition" firmware from iomega. As of this writing, the most-current version was The firmware comes in an encrypted tarball, but your linux distro will make short work of that little problem.
  1. Prepare the ix2 for conversion: Copy all your data to another storage medium. If you brick your ix2, you don't want to be left hanging in the cold.
  2. Create the conversion tarball.
    1. Create a new share on the ix2. Copy the firmware image from iomega to the share.
    2. Save the following code as a shell script in the same place:
      mkdir -p $ix2/images
      mkdir -p $ix2/update
      mkdir -p $ix2/apps
      openssl enc -d -aes-128-cbc -in $ifw -k "EMCNTGSOHO" -out $ofw
      tar xzvf $ofw -C $ix2/update/
      imgs=$(find $ix2/update/)
      for img in ${imgs} ; do
        if [ -f $img.md5 ] ; then
          mv $img $ix2/images/
          mv $img.md5 $ix2/images/
      mount -o loop,ro $ix2/images/apps $ix2/apps
      cp -p $ix2/apps/usr/local/cfg/config.gz $ix2/images/
      umount $ix2/apps
      gunzip $ix2/images/config.gz
      md5=$(md5sum $img)
      md5=${md5% *}
      md5=${md5% }
      echo "$md5" > $img.md5
      cd $ix2/images/
      tar czvf ../ix2-boot.tgz *
      You will need to edit the first line of the script to match the filename of the firmware tarball you placed in the folder with the script.
    3. Log on to the ix2 using SSH. (the first part of this post will walk you through gaining SSH access to your ix2)
    4. Verify you have an available loopback device to use as a mountpoint: losetup -f
      • if losetup indicates that there are no free loop devices, you need to create the next one in sequence.
      • Determine the next-needed loop device with: losetup -a
        The output will probably look a bit like this:
        root@ix2:/# losetup -a
        /dev/loop0: [0900]:15970 (/sysroot/boot/images/apps)
        /dev/loop1: [0900]:47905 (sysroot/boot/images/config)
        /dev/loop2: [0900]:15972 (/sysroot/boot/images/oem)
      • As indicated above, the first 3 loops are in use (loop0 through loop2), so the next one needed is loop3.
      • Use the following command to make loop3 (the 4th loop device):
        mknod -m 0600 /dev/loop3 b 7 3
    5. Change to the directory of the share you created:
      cd /mnt/soho_storage/samba/shares/sharename
    6. Make the script executable:
      chmod 700 scriptname
    7. Execute the script:
      The script will take a while to run: the original tarball must be unpacked, several files get copied, a new tarball is built. It's time-consuming, especially on low-powered hardware like the ix2. But nothing you're doing is affecting the existing system; you're simply using a handy linux environment to get some work done.
    8. The final result will be a new file in the *-files folder called ix2-boot.tgz. Back on your main workstation, copy this new tarball to your USB drive in the following directory tree:
    9. Exit the SSH shell
  3. The drives that will be targeted for the conversion must be clean/clear drives; preferably, they will be new drives that have never been used, with no existing partition table. If you're going to re-use the existing ix2 drives, or re-use drives that you've had in another system, you first need to wipe them out: delete any existing partitions. The conversion won't work if you have data on the drives. This is where your mettle as a gadget geek gets tested: do you throw caution to the wind and wipe the ix2 drives, or do you get new drives and "play it safe?"
  4. Place the new/wiped drives into the ix2.
  5. Plug in the USB drive to any of the three ports.
  6. Press and continue to hold the reset button on the back of the unit while plugging in the power supply. The ix2 will automatically boot when power is applied, and if you don't keep the reset button depressed for the entire boot sequence, you will not activate the installation. Watch your USB activity light; although it will come on when the unit activates the drive, you need to keep the reset button depressed until regular activity (i.e., blinking) is observed. In my experience, this takes approximately 90 seconds from the moment you plug in the power supply.
  7. Wait. The update will occur, and you'll see plenty of activity for the drive indicator on both the USB drive and the ix2. After less than 10 minutes, however, the ix2 will automatically power off.
  8. Remove the USB drive. Reconnect the network. Power up the ix2.
If you successfully updated the image, the indicator lamps on the front of the unit will blink furiously for a few minutes. Once the main power indicator (bottom lamp) is solid, you should be able to reach the management console via browser (Hopefully, you have some way to tell what the IP address is; your router or other DHCP server should have a way to indicate the address—I use a DHCP reservation, so I always get the same address, regardless of configuration state for the unit).

If you don't get that far—the bottom lamp blinks, the drive lamp blinked a couple of times, but otherwise, no activity—don't despair: I've seen other postings that indicate success when performing the procedure twice; I never needed it (I've repeated the update three times so far). Worst-case: you pull the drives and replace your original ix2 drives. Nothing is stored locally on the device, so a clean drive swap is possible.

The second alert lamp will blink until data protection is complete (either because you switched to a "none" option or it finished setting up the mirror); you can expect the drive activity lamp to be lit solid during the data protection phase.

By default, the firmware wants the ix2 to be using mirrored protection. You can alter that through the setup, and with the cloud version, you have the option of using "linear" or "raid0" if you want to get optimal performance at the expense of data protection.

Once you have the device configured the way you prefer, recreate your shares and iscsi volumes and put your data back on the unit: you're now Cloud-Ready!

The science and tech fields have historically worked by advancing based on prior works; we don't reinvent the wheel, we take the various works of our predecessors and advance "the art" through mash-ups that fail more often than they succeed.

This is one of those mash-ups, and thanks go to the following...

Thursday, September 15, 2011

iomega px6-300d: first look

The iomega px6-300d is a storage appliance that can be provisioned with up to six SATA drives, both traditional rotating-disk and SSD. It is one of four NAS/SAN appliances in the "px" line from iomega, and is the largest-capacity "desktop" model.
Under the hood, it contains a dual-core Intel Atom processor (running at 1.8GHz) with 2GB RAM, sports a pair of Gigabit Ethernet ports, three USB ports (1 x USB 3.0, 2 x USB 2.0), and runs a customized version of Linux called "EMC LifeLine." The unit can be purchased with various pre-installed drive configurations (6, 12 & 18TB raw capacity); along with the px4 models, iomega has also (finally!) offered a "diskless" configuration.
Retail Box
I purchased a diskless unit ($750 from B&H) for use in my home lab, and independently acquired a matched set of six 2TB Hitachi 7200RPM SATA-III drives (HDS723020BLA642, $110 from NewEgg). This 12TB (raw) setup cost me less than $1500; in contrast, the list price for a pre-populated 12TB unit is $3,299.99.
The unit came in a nice retail box, and was well-padded and packed. In addition to the unit itself, the package contained the external power supply, power cord, CAT5e Ethernet cable, a "Quick Start Guide" and a "Solutions CD."
px6-300d front
px6-300d rear
The front of the unit provides drive access, power button, information display (and a pair of input buttons) and one USB port; the rear of the unit has a pair of 90mm fans, the power connection, reset button, Gigabit Ethernet ports and a pair of USB ports. The rear also sports (what appears to be) a surprising and undocumented x1 PCIe expansion slot.
The Quick Start Guide instructs the owner to install software from the Solutions CD, which will then assist in installing the array; having experience with the ix line, I simply created a DHCP reservation (the MAC address is documented with a sticker on the rear of the unit), connected it to Having purchased a diskless unit, I was curious to see how the system would behave when booted with no drives. True to form, this situation was handled gracefully.
front door open, showing drive trays
drive trays with 2.5", 3.5" drives

trays line up SATA connector
Up to six drives can be installed using supplied hot-swap trays, which support both 3.5" and 2.5" form-factor drives. In addition to the matched drives, I also had a 2.5" SSD available for testing, but the supplied screws didn't fit the drive properly; it was a bit of a struggle to find screws that would not only work with the drive, but also work with the sled: the smaller drives must be attached to the sled from the bottom, so care must be given to make sure the screws do not protrude too far from the bottom of the sled.
The unit I received was pre-installed with an out-of-date firmware (3.1.10; 3.1.14 most current as of this posting), which booted correctly even without any drives installed in the unit. This is a distinct departure from the "ix" line of NAS boxes, which require at least one functioning drive to store the firmware (which also explains why the older lines didn't support a diskless purchase option). The management interface will not allow you to do anything until at least one drive is installed, however, so that was the first order of business.

After installing the first drive, the management interface permitted me to add the unit to my Windows domain, and I also went through the exercise of downloading and updating the firmware. This is a very easy process, so novice users shouldn't be afraid of it.
The unit supports a wide variety of RAID levels, and the user can combine arbitrary combinations of drives into "storage pools" so that the unit can provide different levels of performance based on your needs, so I will be testing the various permutations with increasing spindle counts.
Storage Pool Protection Options
2None, RAID0, RAID1
3None, RAID0, RAID5
4None, RAID0, RAID1/0, RAID5
5None, RAID0, RAID5
6None, RAID0, RAID1/0, RAID5, RAID6
Once you create a storage pool, you can create one or more NAS volume (for CIFS, NFS or other share-types) or iSCSI volumes in it. When creating a file-sharing volume, the unit can recognize space utilization on a file-by-file basis, and will display free/used space as one would expect. A volume used for iSCSI will appear to be 100% allocated as soon as it is created, even if no initiator has ever connected and accessed the LUN. Additionally, multiple shares can be created for a single file-sharing volume, but there's a one-to-one mapping between an iSCSI volume and a target. Security for either file shares or iSCSI is optional; the unit defaults to read/write permissions for everyone.
There are a number of nice features that I'll investigate further, but the first order of business is performance testing. With luck, I'll learn that the device can scale with each added spindle; it will also be interesting to see how much of a performance hit the device will take when using RAID6 instead of RAID5 in the 6-spindle configuration.