So, I bought a Roku a few months ago after my dad bought one. He got one of the first generation devices, as well as a second. It was able to play his ripped media, with a little coaxing, but the feature that caught both of our attentions was the 1080p playback. I decided to buy a second generation as well, since it had the ability to create third-party apps (they call them channels).

I started to program for the Roku, only to be first struck by the programming language. While it has similarities to several other scripting languages, it is a new programming language. Those out there familiar with the realities in computer science are screaming in the heads how this is a poor decision, but they made it anyway. I was then struck by the complete lack of library availability. Unfortunately, I had allowed myself to accept the premise that I had no choice in the matter and tried my best to plow on. My father and I had designed a Java server, which facilitated transcoding of files to be served to the Roku. I then started to add in the metadata features found in Sapphire to this server. I had browsing working from the device as well as playback initiated from the device. It was starting to look like a replacement for my AppleTV running Sapphire.

Then came the updates. Roku issues a firmware update, which caused numerous problems. The most notable was when one would play an MP3 on the first generation device (streaming a radio station for instance), then later played an MP4 with H.264, the device locked up requiring a reboot. This bug took a month and a half to fix. Additionally, the HLS streaming, which is what’s used to deliver the transcoded data to the device, was suffering from numerous audio dropouts. Supposedly, this bug was fixed in the update that was released today, but I’ve found reports of this bug in the firmware betas dating as far back as May. This means that roku was aware of the regression for 5 months before releasing the firmware. Furthermore, try to report this bug on their forums, and the fanbois descend on you like a coming plague, insisting that nothing is broken, or that a fix is coming and you must be patient. I’ve even seen some do both, even though they are diametrically apposed positions. I then noticed a firmware update on my second generation roku including some of the same regressions.

I’ve had it.

I decided to get something else. When I looked at the list of options, I narrowed my choice down to AndroidTV and GoogleTV. AndroidTV is essentially hardware vendors taking the open sourced Android OS (the versions that are), and putting in on their devices. GoogleTV is the Android OS, with some additional addons including a large host of codec/container support. I went with the latter, so I now had to pick which device. Sony makes a BluRay player and several TVs, and Logitech used to make their Revue. I went with the BluRay player since it was not discontinued and I didn’t want to buy a TV right now. Also, the GoogleTV’s new firmware is based on Android 3.1, and the AndroidTV devices are mostly on 2.2 or 2.3.

When the device arrived, I started doing some tests. It played nearly everything I threw at it without issue. I played everything over http, just giving the built-in VideoView class a URL to play, and it played it. I tested MKV, AVI, MP4, and MKV files. All had no issues. It even played the killa sample, which is something that the roku failed to play. The programming language is far better, since they used Java, and the programming environment actually works instead of the occasional lockup of the device in the debugger from which the roku suffers. It’s also much faster, and stable. My dad found that Amazon was still selling the Revue, so he bought one based on these results. I don’t know what we are going to do with our roku devices. I expect I may finish the Angry Birds levels, then call it failed experiment and box it up.

In short, don’t buy from roku. Buy a GoogleTV instead. Yes, they are more expensive, but you truly get what you pay for here. The programming environment is far superior, which means the apps will be better. The device works, and it appears that Google actually does regression testing. Additionally, Google appears to be ambitious in the devices future. It looks like GoogleTV truly is the route to go. I just wish I had seen it earlier.

BTW, I plan on fully porting Sapphire over to work on the GoogleTV in a client-server relationship. I’m doing this because I plan to allow sharing a single library across multiple devices. I don’t know yet whether I intend to release it to the public. Sometimes it is nice not having to deal with “customer” support. Browsing and playback is done, as well as an importer to read the previous version’s metadata. All that’s left is the metadata importing of new files. Time will tell on where I go with this.

I started this because one movie, I don’t remember which one, forced me to wait on FBI warning, another copyright violation warning, the same in French, and a disclaimer. Then it displayed two previews and a lengthy menu before I could hit play. This was followed by another lengthy menu animation, studio logos, and finally the movie. In the whole process, the studio logos and the previews were the only portions I was able to skip, the other screens marked as not skippable on the DVD. Now that I have my DVDs ripped, when I want to watch a movie, I browse my collection on the TV, and play the movie. No warnings, no menus, just the movie. I actually moved 8 months ago, and I have yet to unpack the DVD player.

This past weekend, I was at my parents’ house and I played a few of their BluRay disks. One movie, I think it was Flyboys, spent a considerable amount of time on the loading screen, had large sections of menus/screens that were not skippable, even included a section where it tried to download a trailer. Once the movie started playing, I paused it and to help feed some kitties and give them attention for a few minutes only to return to a custom screen saver of some sort. The movie would not resume. Upon repeating the process, a total of 15 minutes was wasted excluding the time spent with the movie paused.

So now, I seriously question the value of keeping media in these physical formats. I was considering BluRay in the near future, but now I think I’ll elect to forgo a player for an external drive and rip every disk that I might buy. Now I just need to find a good external drive that allows easy ripping. Thoughts?

I did consider FreeNAS for a really long time. It is essentially a FreeBSD install with most of the administrative work done for you through a web-based GUI. It hit most of my checkboxes in that it supported ZFS, AFP, Bonjour, and a few others. While this is nice, I found it also to be limiting when one wants to stray off the beaten path. I didn’t want to lose ZFS, but I wanted something where I could tinker. I decided to go with FreeBSD.

One of the first things I tried with FreeBSD, as the topic indicates, is to put the root filesystem on ZFS. I followed an excellent tutorial to start, but decided to make a few modifications:

• I wanted to put the root filesystem some place other than the root of the pool. Since my large media collection is going to be stored on the same pool, I wanted the ability to selectively snapshot the boot filesystem, and possibly revert it, without affecting the media partition. So, I put the root filesystem on on a sub filesystem of the pool.
• The trend in disk storage is looking like it will go to 4K sector sizes in the future. ZFS cannot migrate a pool from 512 byte sector sizes to 4K sector sizes without a reformat/restore. I wanted a 4K sector size pool from the start.
• I wanted to use ZFS swap instead of swap partitions.
• I was going to spent several iterations getting things right and didn’t want to type on that blasted 12 year old keyboard the same commands over and over.

So, I accomplished this whole task through a series of scripts, that I would modify. If the script did something wrong, I’d destroy the pool and start over. The end result is a simple setup that I decided to share with the world:

1. Download and burn/image one of the FreeBSD iso images or USB images. I used 8.2, the most recent at the time of this writing, and did the USB image since I had flash drives to spare but no DVD ROM drives.
2. Boot the machine and enter the recovery mode (Fixit).
3. Start the networking:
   mkdir /var/db
dhclient em0
ln -s /dist/usr/bin /usr/bin

4. Transfer over the script directory:
   scp -r username@10.0.0.10:Desktop/FreeBSD/\* .
   In this case, 10.0.0.10 is my laptop with sshd running.
5. Start sshd: ./FreeBSDSSHSetup.sh
6. ssh into the machine from my laptop and execute: ./FreeBSDInstall.sh
7. Reboot the server and enjoy.

The FreeBSD directory is available for those who would like to copy my efforts, though they will likely need some modification to suit your needs. The gptzfsboot, pmbr, and zfsloader files came from this site which are modified versions that work with 4K drives. The versions available in 8.2 do not work with 4K sector sizes, but future versions will. My install script

• Partitions ad8, 10, 12, 14, 16, 18 to contain the boot loader and zpool information (6 SATA drives),
• Loads kernel modules and sets up a gnop drive with 4K sectors,
• Creates a raidz2 pool using the gnop drive as one of the drives forcing 4K sectors, exports the pool,
• Destroys the gnop drive, re-import the pool, which had been forced to 4K sectors,
• Sets up root filesystem on zroot/root (zroot is the root of the pool, root is the root filesystem, as discussed above), and
• Performs a standard zroot install, except no swap partition.

I actually added the swap later, which is simply:
zfs create -V 2G zroot/swap
zfs set org.freebsd:swap=on zroot/swap
zfs set checksum=off zroot/swap


And that’s it. I have my 8TB raid running, with 2 drive redundancy, booting off the raid. Setting up AFP and the like requires more tinkering than with FreeNAS, but the instructions are easy to find and would be redundant to list here.

For one who has programmed in other object oriented languages, Objective-C stands out with its complete lack of namespace. As a result, classes have a prefix, such as Apple’s common NS and UI prefixes. On the mac side of things, every class under the sun seemed to start with NS, such as NSString, and confusion is added when on the iOS side, several classes start with UI, such as UIView. This is due to the fact that without a concept of namespace, Objective-C cannot have two classes with the same name, regardless of whether the classes are public or not.

If I were designing an application which communicated on a network as well as talked to a database, I would split the two pieces into separate segments, or in Java, packages. Inside each package, I would likely have a Connection class, which has completely different meanings within the network and database packages. Inside those packages, especially if the Connection class was internal to the package only, I could name both classes Connection without any concern and the code inside the package would immediately understand what Connection actually meant. This is possible in Java because the actual class names are com.cod3r.app.network.Connection and com.cod3r.app.database.Connection. Since Objective-C does not have namespaces, I would have to name these NetworkConnection and DatabaseConnection.

Now, take the above scenario, and add another type of network connection. Then take that new network connection and add new specific case to it, making a new class. In Java, the package name gets longer where as in Objective-C the class name gets longer. I have run into cases where this borders on ridiculous if one wants the class name to define what it actually does without ambiguity. The class is within the Sapphire plugin. In the project, all classes had the prefix Sapphire since it was a bundle included in another application and had to make sure there was never a class conflict. The project has the concept of a Directory and a VirtualDirectory was a directory which wasn’t associated with a directory in the file system. There is a type of VirtualDirectory that was Custom meaning it was defined by the user instead of already in the code. Finally, this particular class is responsible for importing these CustomVirtualDirectory objects, making the final class titled SapphireCustomVirtualDirectoryImporter. In Java, this class would have been Importer within the net.nanopi.sapphire.directory.virtual.custom package. The difference is the fully qualified classname would only be used in the import statement, and the short class name would be used in the code, instead of the really long classname used in every location as seen in Objective-C. This becomes particularly relevant when it comes to code completion that produces a terribly long list until nearly the entire class name is typed.

The lack of namespace becomes problematic when one uses third party libraries. Take the above Sapphire example and another plugin developer finds a completely unrelated library titled Sapphire. If that library happened to have a directory titled SapphireDirectory, then both plugins cannot be loaded at the same time. Java goes even further with a two-level namespace such that two jars (bundles) with the same fully-qualified classname still don’t interfere since they are in separate jars.

Adding namespace is necessary for adding inner-classes, which Objective-C outright doesn’t use, but could in proper circumstances. Inner classes are useful for implementing delegate methods. When setting a delegate, one typically passed in the instance of an inner class rather than the current instance. Not adopting this model has the issue when a single class is set to be the delegate to multiple objects, such as being the delegate to two table views. Apple works around this design by making each delegate method have the first parameter be that of the object calling it’s delegate, such as the table view. This means if the code is different between the two, every single delegate method needs have an if statement to determine which table view is being processed, and eliminates the ability of one to skip implementing an optional method for one table but not the other. Both of these problems are eliminated with inner-classes. Finally, the lack of inner-classes severely cripples the ability of a super-class to use the Key Value Observing within Objective-C since the delegate and unregister methods were written in a way that really require an inner-class to work properly (I can see how to easily break some code in a sub-class or super-class since this was designed so badly).

Impact on Runtime:
Small. I don’t know the specifics of the runtime, so I can’t judge the exact impact, but this will result in longer effective class names, which may increase lookup times. Inner-classes would need an instance variable for their outer-class to access it’s instance variables, resulting in additional pointer deference for accessing outer-class variables.

Impact on Code:
No longer need to create necessarily long class names; programmer can use short class name without concern. Frameworks need not have a class prefix. More flexibility in object design.

I talked with their live support to confirm this flaw, and amid a bastardized, CPU-hogging chat client, I managed to get confirmation that this flaw is known, and no explanation as to why it has not been fixed aside from “I’m sorry, that’s what the camcorder can handle.”

I later found out that the company is owned by Cisco, and considering my history with their lousy products in the past, I should have already known.

Background
First, some background on how drives work internally: A hard drive stores data on the platters in blocks, or sectors. The sector size is typically 512 bytes for a magnetic disk. With each sector, the disk must store a start code and an Error Correction Code (ECC). The start code is necessary so the disk can find a particular sector, and the ECC is necessary to correct any errors in the data read from the disk.
Western Digital decided to change from 512 byte sectors to 4096 byte sectors. This means that the new sector can store the same amount of data as 8 of the previous sectors. Since each sector needs a start code, this means there are now 7 fewer start codes for each new sector.
The ECC of the 4096 byte sector needs to be larger than the ECC of a 512 byte sector, but it doesn’t need to be 8 times as big. This is due to the fact that ECC is better at correcting errors with larger block sizes and thus a lower rate (or percentage in size) ECC can achieve the same Bit Error Rate (BER). Interesting side note: Hard drives are designed to store data so compactly and so close to the limits of the hardware that data is expected to have some corruption as it was stored, and rely on the ECC to correct the corruption. In fact, the manufactures intentionally design the drives so that it will have a few corruptions but few enough that the ECC can handle it.
With the reduction in the number of start codes, and decrease in ECC rate, larger sector sizes allow for greater density of data on the drive itself.

Writing Sectors
When a computer does a read, it reads an entire sector at a time. When it does a write, it, again, writes an entire sector at a time. There is no such mechanism to write only a part of a sector. Western Digital’s EARS drives have 4096-byte sectors, but the drive claims it has 512-byte sectors (since some opperating systems still in use cannot handle different sector sizes). This means that the drive does some work internally to handle this difference. Often, when writing data to a hard drive, multiple consecutive sectors are written. If a computer writes 8 512-byte sectors in a row, which all correspond to the same 4096-byte sector, then the drive can simply wait until all 8 sectors are written and write out all the data as a single 4096-byte sector. This is what the EARS drives do when sectors are written. If not all 8 sectors are written, then the drive has to do a partial sector write. This is typically not the case since many file system operate on 4096-byte blocks, and thus write 4096 bytes at a time.

Partial Sector Write
If not all 8 512-byte sectors in a 4096-byte sector are written, then the drive has to write part of a sector. So, the drive must find the data on the drive, and write the part of the sector that has changed, right?
Wrong. The problem is the ECC was written with the 4096 bytes that was there previously, so it must be updated. Due to the nature of how the ECC is computed, one cannot write a new ECC without first reading at least some of the data that was in the original sector. While it is possible to read the data to be overwritten, the old ECC, and compute the new ECC, this can propagate errors beyond the ECC’s ability to correct. So, the drive must read the 4096-byte sector, correct any data errors in the sector, substitute in the changed data, compute the new ECC, wait for that part of the drive to spin around again, and write the data to the drive. In comparison, if all 8 512-byte sectors were written, then the drive need only compute the new ECC and write the data.
So, if a single 512-byte sector is written, the drive must read 4096 bytes, wait for a rotation, and then write 4096 bytes. On a 7200 RPM drive, the waiting for a single rotation is 8.333 ms. If one assumes no smart scheduling, this results in a maximum throughput of a megabyte every 2 seconds, which is reminiscent of drives from the previous decade. Obviously, intelligent scheduling is utilized, but in the best case scenario, the drives performance will be dropped to half. From this, one can see that it is crucial to always write 4096 bytes at a time to get the best performance.

Alignment
As stated in the previous section, the best performance comes when 4096 bytes is written at a time, but this data must also be properly aligned. If 2048 bytes is written to one sector and 2048 to the next, then this involves 2 reads and 2 writes of 4096 bytes each. So all writes must be aligned on 8 sector boundaries (sector 0, 8, 16, 24, 32, etc) This is why Western Digital put in a jumper to help with the alignment since some formatting methods start on sector 63, which is not an 8 sector boundary. Those on Unix/Linux systems must pay special attention to this when formatting the drive.

Solutions
The solutions depend on the file system you are using. If you know your file system uses 4096-byte blocks, then you only need to ensure that the file system is properly aligned on 8-sector boundaries. So, when partitioning the drive, ensure that the partition offsets are divisible by 8.

ZFS
So, what does this have to do with ZFS? ZFS doesn’t have a pre-set block size. It uses variable sized blocks depending on the amount of data it is writing. If it’s writing 1000 bytes, then it will write the minimum number of sectors necessary to fit that data, which in the case of 512-byte sectors, is 2. This means that writing 1000 bytes requires reading and writing 4096 bytes or maybe 8192 depending on alignment. This means that properly aligning the partition will not solve the issue with ZFS. Here we need a different solution.

File System Agnostic Solution
The best solution is for the file system to think the drive has 4096-byte sectors. Since the drive will not claim this it needs to be done in software (really Western Digital, did you think this was not worthy of a jumper on the drive? It would have made things much easier). Since ZFS has performance issues on Linux anyway due to it’s kernel’s license, I won’t cover it at all. The primary case I’ve seen this issue raised is from those using FreeNAS on FreeBSD. Here, there are two solutions, depending on whether you want your drive encrypted or not. Both of these solutions give a new device, which the rest of the OS sees as a normal drive, but the drive has 4096-byte sectors, which are properly aligned. Warning, both of these methods destroy the data on the drive.
Not Encrypted
The drive can be presented as a drive with 4096-byte sectors by using gnop. Here is how one would create a raidz1 pool for da1-4:
for i in da1 da2 da3 da4; do gnop create -S 4096 $i; done
zpool create tank da1.nop da2.nop da3.nop da4.nop
The for loop must be run on each reboot otherwise ZFS will not see the da*.nop devices.
Encrytped
The encryption setup is similar:
for i in da1 da2 da3 da4; do geli init -s 4096 $i; done
for i in da1 da2 da3 da4; do geli attach $i; done
zpool create tank da1.eli da2.eli da3.eli da4.eli
Here the second for loop needs to be executed on each reboot. On FreeNAS, the encryption can be made simpler by setting up the drives in the GUI to use encryption, then after the encryption is setup, go into the shell, and execute the two for loops, then continue setting up the encrypted drive in the gui to use ZFS.

So, that’s how to handle ZFS on WD EARS drives. I’ve read reports that some, if not all, of what I described in the solutions will be in the next version of FreeNAS. Here’s hoping that it will.

BTW, the primary legacy Operating System that cannot properly handle the 4096-byte sector is Windows XP.

The problem is the following: A Raid-Z configuration uses n partitions, giving the user the capacity of n-1 of those partitions, with the nth being the redundant to survive a failure. If the n partitions are not the same size, with the smallest being x, only the first x bytes of each partition is used. One cannot remove a Raid-Z from an active pool without a backup/restore. One cannot add a disk to a Raid-Z without a backup/restore (maybe in the future). The only expansion that can be done is to replace the partitions with larger ones, and once the smallest partition is increased, the available space increases.

For the purposes of demonstrating this technique, I will use an example with 4 disks:

• 125G
• 250G
• 500G
• 750G

The biggest theoretical capacity of the array, while retaining single disk failure resiliency, is simply the total size of the array minus the largest disk. This means that the capacity of the above example is 875G. So, how does one achieve this capacity? I proposed the following structure using 3 raids:

If you add the capacity in the above, you can see it is 3*125G + 2*125G + 250G = 875G, which is the theoretical capacity.

Suppose I wish to replace the smallest disk, 125G, with a new disk, say 1T. Using the same layout, I should see something like this:

If you add the capacity in the above, you can see it is 3*250G + 2*250G + 250G = 1500G, which again is the theoretical capacity.

The question is, can I migrate from the first configuration to the last without a backup/restore process? The answer is YES, and data is moved/copied at most once.

For the purposes of demonstration, I’m going to show the expansion with 5 drives connected, but the expansion can be done by immediately replacing the smallest drive with the largest and relying on the redundancy to keep things intact in the process.

First, connect the 1T drive and partition it as 250G, 250G, 250G, leaving the rest free. Replace the first 125G partition on 750G disk with the first 250G partition on the 1T disk:

Continue the replacement:

Repeat the same process with the 3 partitions on the 500G disk:

At this point, the move of the blue raid is complete. Depending on the sizes of the disks, the blue raid may be bigger, at which point the pool immediately increases in size. In this example, it does not change size.

Repeat with the 2 partitions on the 250G disk:

At this point, the red raid is complete. In this example, the red raid has changed from 250G to 500G, and the job isn’t complete yet!

Repeat for the final time with partition on the 125G disk:

Now we are done, and can disconnect the 125G disk if not done already. In this example, the green raid has changed from 375G to 750G, yielding a total change of 875G to 1500G.

Note: There is one limitation with this structure. Ordering the disks in increasing size, disk(n) must be at least as big as 2*(disk(n-1))-disk(n-2). This essentially means that if a disk is xG bigger than it’s previous disk, then the next disk must be at least xG bigger than this disk. Since disk sizes tend to grow exponentially, this assumption shouldn’t be much of a problem since the requirement is at least linear growth.

The disk sizes in this example meet the requirement I listed above. Given the requirements of this expansion, the disk added in this example must be at least 1000G, since disk 4 is 250G bigger than disk 3, disk 5 must be at least 250G bigger than disk 4, or 1000G.

This technique also allows adding another disk, under the same conditions. Consider adding a 1T disk and creating another Raid-Z:

I didn’t structure the partitions in nice pretty rows to demonstrate the fact that not all of the data needs to be moved (in this case, 750G of data is not moved). In this example, the capacity increased from 875G to 1625G, again the theoretical capacity.

Anyway, I thought of this while considering using ZFS/Raid-Z in a FreeNAS setup. I haven’t tested any of this; it’s theoretical only. What do you think?

I started to suspect that this was my fault, since this one podcast, Escape Pod was a podcast I was listening by going through its archives. I had written a program which downloads the archived episodes, and modifies the ID3 tags so iTunes will properly recognize the file as a podcast and insert it into its database as if it had downloaded it itself. Getting the release date working correctly was one of the harder points, so I figured that I still didn’t have it quite correct and the new iPod firmware was being more sensitive to it. I got even more annoyed by the fact that iTunes, after upgrading my iPod’s firmware, decided to trash the old firmware versions preventing me from ever downgrading.

Then, I read online discussions where others were having this problem. Now I know that it is not my fault, but rather something that Apple screwed up. I also saw someone who noted that they had upgraded their iTunes, but not their iPod, and had the same issue. So, I trashed iTunes, pulled out my Snow Leopard disk, found the iTunes package on the disk, installed it, reverted my iTunes library to the backup prior to the upgrade, and voila, my podcasts are sorting correctly again.

Now if only I will learn to let others try first, and upgrade myself after reading their reports. This is a really sloppy bug on Apple’s part, and likely means that iTunes 9 was rush. I’m actually happier back on 8, especially since the window zoom still functions as a toggle between the mini player and the normal window, which was changed in 9.

Hopefully someone will benefit from this post, and not upgrade to iTunes 9 until this regression is resolved.

The whole ordeal was mostly due to the CARS program, which is often known by “Cash for Clunkers”. Anyway, I finally got that resolved and got a lot more for my old truck than I would have ever gotten in trade-in value. So now I have a VW Jetta, and so far I’m happy with it. I just need to get used to driving a car instead of a truck, but otherwise it drives well.