*Coder Blog

Life, Technology, and Meteorology

Month: September 2014

Setting up a Small Desktop RAID System

With the exodus of mass internal storage hitting even the top end of the line in the 2013 Mac Pro, a lot more people are going to start looking for external solutions for their storage needs. Many will just buy an external hard drive or two, but others like myself will start to consider larger external storage arrays. One of the best solutions for people who need 5-15GB of storage is a 4 disk RAID 5 system. As I mentioned in a previous post, I went with a Pegasus2, and set it up in a RAID 5. This brings up a lot of questions about individual RAID settings though, so I thought I would put together a primer on typical RAID settings you should care about when purchasing a Pegasus or comparable desktop RAID system.

Stripe Size
Stripe size is probably the setting that has one of the biggest impacts on performance of your RAID. A lot of people will run a benchmark or two with different stripe sizes and incorrectly determine that bigger stripe sizes are faster, and use them. In reality, the best performing stripe size highly depends on your workload.

A quick diversion to RAID theory is required before we can talk about stripe sizing. With RAID 5, each drive is split up into blocks of a certain size called stripes. In a 4 disk RAID 5, 3 disks will have real data in their stripes, and the 4th disk will have parity data in it’s stripe (in reality, the parity stripes in a RAID 5 alternate between drives, so not all the parity is on the same disk). The parity stripe allows a disk to fail while still keeping your array online. You give up 25% of the space to gain a certain amount of redundancy.

When you read data from the volume, the RAID will determine which disk your data is on, read the stripe and return the requested data. This is pretty straightforward, and the impact of stripe size during reading is minimal.

However, when writing data to the disk, stripe size can make a big performance difference. Here’s what happens every time you change a file on disk:

  1. Your Mac sends the file to the RAID controller to write the change to the volume.
  2. The RAID controller reads the stripe of data off the disk where the data will reside.
  3. The RAID controller updates the contents of the stripe and writes it back to the disk.
  4. The RAID controller then reads the stripes of data in the same set from the other disks in the volume.
  5. The RAID controller recalculates the parity stripe.
  6. The parity slice is written to the final disk in the volume.

This results in 3 stripe reads, and 4 stripe writes every time you write even the smallest file to the disk. Most RAIDs will default to a 128KB stripe size, and will typically give you a stripe size range anywhere from 32KB to 1MB. In the example above, assuming a 128KB stripe size, even a change to a 2KB file will result in almost 1MB of data being read/written to the disks. If a 1MB stripe size is used instead of 128KB, then 7MB of data would be accessed on the disks just to change that same 2KB file. So as you can see, the stripe size greatly determines the amount of disk I/O required to perform even simple operations.

So why not just choose the smallest stripe size? Well, hard drives are really good at reading contiguous blocks of data quickly. If you are reading/writing large files, grouping those accesses into larger stripe sizes will greatly increase the transfer rate.

In general, if you use mostly large files (video, uncompressed audio, large images), then you want a big stripe size (512KB – 1MB). If you have mostly very small files, then you want a small stripe size (32KB – 64KB). If you have a pretty good mix between the two, then 128KB – 256KB is your best bet.

Read Ahead Cache
A lot of RAID systems will give you the option of enabling a read ahead cache. Enabling this can dramatically increase your read speeds, but only in certain situations. In other situations, it can increase the load on your hard drives without any benefit.

Let’s talk about what happens in the read cache when read ahead is disabled. The read cache will only store data that you recently requested from the RAID volume. If you request the same data again, then the cache will already have that data ready for you on demand without requiring any disk I/O. Handy.

Now how is it different when read ahead caching is enabled? Well, with read ahead caching, the RAID controller will try and guess what data you’ll want to see next. It does this by reading more data off the disks than you request. So for example, if your Mac reads the first part of a bigger file, the RAID controller will read the subsequent bytes of that file into cache, assuming that you might need them soon (if you wanted to read the next part of the big file, for example).

This comes in handy in some situations. Like I mentioned earlier, hard drives are good at reading big contiguous blocks of data quickly. So if you are playing a big movie file, for instance, the RAID controller might read the entire movie into cache as soon as the first part of the file is requested. Then as you play the movie, the cache already has the data you need available. The subsequent data is not only available more quickly, but the other disks in your RAID volume are also free to handle other requests.

However, the read ahead results in wasted I/O. A lot of times, you won’t have any need for the subsequent blocks on the disk. For instance, if you are reading a small file that is entirely contained in a single stripe on the volume, there is no point in reading the next stripe. It just puts more load on the physical disks and takes more space in the cache, without any benefit.

Personally, I enable read ahead caching. It’s not always a win-win, but it can greatly speed up access times when working with bigger files (when the speed is needed most).

Write Back Cache
There are two write cache modes: write through, and write back. Your choice here can have a dramatic impact on the write speed to your RAID. Here’s how each mode works.

Write Through: When writing data to the disk, the cache is not used. Instead, OS X will tell the RAID to write the data to the drive, and the RAID controller waits for the data to be completely written to the drives before letting OS X know the operation was completed successfully.

Write Back: This uses the cache when writing data to the disk. In this case, OS X tells the RAID to write a given block of data to the disk. The RAID controller saves this block quickly in the cache and tells OS X the write was successful immediately. The data is not actually written to the disks until some time later (not too much later, just as soon as the disks can seek to the right location and perform the write operation).

Enabling the write back cache is “less safe” than write through mode. The safety issue comes into play during a power outage. If the power goes out between the time that the RAID told OS X the data was written, and the time when the data is actually on the disks themselves, data corruption could take place.

More expensive RAID systems, like the Pegasus2, have a battery-backed cache. The benefit here is that if a power outage happens as described above, the battery should power the cache until the power goes back on and the RAID controller can finish writing the cache to disks. This effectively overcomes the drawback of enabling write back caching.

Another potential drawback for enabled write back caching is a performance hit to the read speed. The reason for this is that there is less cache available for reading (because some is being used for writes). The hit should be pretty minor though, and only applicable when a lot of write operations are in progress. Otherwise, the amount of data in the write back cache will be minimal.

The big advantage of using a write back cache is speed though.  When write back caching is enabled, OS X doesn’t have to wait for data to be written to the disks, and can move on to other operations.  This performance benefit can be substantial, and gives the RAID controller more flexibility to optimize the order of write operations to the disks based on the locations of data being written.  Personally, I enable write back caching.

Wrap-up

That about covers it.  Small desktop RAID systems are a nice way to get a consolidated block of storage with some a little redundancy and a lot more performance than just a stack of disks can provide.  I hope this overview has helped you choose the options that are best for your desktop RAID system. In the end, there is no right answer to the settings everyone should use. Choose the settings that best fit your workload and performance/safety requirements.

Apple’s Rumored 12″ Notebook

The rumors are growing for a new 12 inch MacBook Air.  According to MacRumors, this laptop would be slimmer than the current MacBook Airs, fanless, and come in the same silver/gold/space gray color variations as the iPhone.

Sounds like an clamshell iPad with a keyboard to me.

The new notebook has a much thinner design the appears to sacrifice many of the usual ports seen on Apple’s current notebooks and may adopt the new reversible USB Type C connector that has seen its specifications recently finalized.

The MacBook Air has very few ports to begin with (video, USB, headphone and an SD card slot on the 13″).   If you are sacrificing many of the usual ports, you end up with no ports at all, like the iPad.

Interestingly, the report raises some questions about charging on the notebook, indicating that the usual MagSafe port has been removed in favor of a new, unspecified charging method.

Hmm, like a Lightning cable?  It’s reversible too.

In line with previous rumors, the machine is reportedly fanless, suggesting it will adopt an ultra low-power processor such as the Broadwell-Y Core M processors recently announced by Intel.

The A8 is another ultra low-power processor…

Many people prefer the iPad as a productivity machine.  With a standard keyboard attached, you can definitely get some serious work done.  A 12″ iPad with a permanent keyboard attached sounds like a great little mobile computer.

First Impression of the iPhone 6

I’m one of the 4 million people who pre-ordered a new iPhone 6 this past weekend. It arrived earlier today, and I wanted to share some observations after using it for the first couple of hours.

This is a big upgrade for me. I’m upgrading from an iPhone 4, which feels absolutely ancient. At one point, I’m sure it felt amazingly quick, but not anymore. (I have to remind myself that someday this iPhone 6 is going to feel just as slow.) To give you an example, sometimes my iPhone 4 was so slow that it missed incoming calls because sliding to answer wouldn’t happen before voicemail picked up the call. Needless to say, the new iPhone 6 is crazy quick in comparison.

Like most people, I was torn between ordering the iPhone 6 or the 6+, sight unseen. There is a pretty big size difference between the two, and some functionality is lost by choosing the 6. I made some cardboard cutouts to help make my decision easier. The cutout for the 6+ felt way too big in my pocket, so I decided to go with the more comfortable 6. Now that I’m using it, I’m really glad I didn’t order the 6+. The 6, even as the smaller option, is so much bigger than previous iPhones. This is especially true coming from an iPhone 4. I have space for 2 more rows of app icons on each home screen, which is great.

One-handed operation is pretty tough though. My first instinct when trying to reach the top of the screen with my thumb was to shimmy it down in my hand. Well, that’s a big mistake, because I almost dropped it while doing this. So then I tried using the new action that Apple built-in, to double-tap the home button to shift the screen contents downward. This helps a lot, but it’s going to take some time before I have the muscle-memory to do this without thinking about it. I’ll probably use it two-handed most of the time.

As an app developer, I think we are in a bit of a transition when it comes to choosing the best location to place often-used buttons in the user interface. Up until now, the top navigation bar was a good location to put navigation controls. However, with devices becoming larger, that may no longer be the case. Instead, it might make more sense to have a more prominent toolbar on the bottom of the screen. I know I’ll be spending a lot of time thinking about this over the coming months.

One last note on the size I would like to bring up is with respect to the depth. It’s amazing to physically grasp just how thin the iPhone 6 is as a phone. It’s almost difficult to pick up off a table because there isn’t much depth to hold onto. Once you are holding it though, it feels very solid and comfortable.

Moving on, this morning was the first time I’ve used TouchID. I don’t know how I lived without it. Actually I do: I would avoid the inconvenience of a delayed unlock process by not setting a password on my devices. TouchID makes security easy by reading your fingerprint on the home button to unlock the device, and I can’t wait for more 3rd party apps to make use of it in iOS 8.

Speaking of buttons, the power button is now on the side rather than the top of the device. My first impression of this change isn’t good. More than once I’ve tried to tap that button to turn off the phone, and instead did a combo press with the volume button on the other side. The OS gives the volume button priority (which is probably the best choice) and the device stays on. Taking screenshots using the home/power button combination is more difficult too. Aesthetically, the power button placement is nice (both with respect of having a clean top panel, and also having the side buttons laid out symmetrically), but usability would be greatly improved if the button wasn’t directly across from the volume buttons.

Finally, I was originally going to use the iPhone 6 without a case, but due to a few of my observations above I think I might change my mind. The device will be easier to pick up off a table if it has a little bit more depth, which a case would add. And with the almost-drop due to using it one-handed, I would feel more comfortable if I had some protection if the worst was to happen and I actually did drop it on a concrete floor or other hard surface. I’ve never really dropped a phone in the past, but I’m not sure my luck will hold with this model. The third reason buying a case is a good idea is due to the extended camera lens on the back of the device. When setting the iPhone 6 down on a table, it is resting on the camera lens. That invites the possibility of scratching the glass, which as a photographer I would hate to have happen. I will use it for a few weeks before making a final decision, but I expect I’ll be plunking some money down for a case in the near future.

Overall, the iPhone 6 is an awesome upgrade and I couldn’t be happier right now. It’s just going to get better as HealthKit comes online and Apple Pay starts rolling out to commercial locations next month.

© 2017 *Coder Blog

Theme by Anders NorenUp ↑