Archive for June 18, 2014

Wednesday, June 18, 2014 [Tweets] [Favorites]

RocketStor Drive Dock: More Expensive But Reliable

I previously mentioned the Highpoint RocketStor 5212 (Amazon), which is a dock for dual 2.5- or 3.5-inch hard drives that connects via Thunderbolt. USB 3 has always seemed plenty fast to me for backups, so I initially dismissed the RocketStor and its high price. However, I continued to have problems with hard drives spontaneously unmounting during backups. This would, at the least, interrupt hours of work, and at the worst corrupt the data. In some cases, the only way to complete a backup was with multiple passes of SuperDuper’s Smart Update, each one copying a different set of files before failing, until finally all were copied.

The problems occurred with both the NewerTech Voyager S3 (Amazon) and the Anker USB 3.0 Hard Drive Docking Station (Amazon). It occurred with multiple Macs, multiple (of each) drive docks, multiple hard drives of different capacities and brands, multiple backup apps, multiple uninterruptible power supplies (as well as none), with and without any other connected USB devices (including hubs), and in multiple buildings.

I reported the problem to the manufacturers, who seemed not be aware of it, and received replacement drive docks, which didn’t work any better. I also got some recommendations for other brands, although the Amazon reviews did not inspire confidence.

I still don’t know what’s causing these problems, nor why they only affect some users. However, my hypothesis is that it’s related to USB 3. There may be a bug in the Mac OS X driver, although I’ve seen similar reports from Windows 7 users. Perhaps the bug is with the USB 3 on the docks themselves. In any event, every USB 3 drive dock I’ve tried has had the unmounting problem, and none of my older USB 2 drive docks did. (Unfortunately, USB 2 drive docks are much slower and only support capacities up to 2 TB.)

The obvious solution was to try a drive dock that doesn’t use USB 3. This brought me back to the RocketStor, whose price has come down from $219 to $190. Result: through many hours of backups as well as regular use, the RocketStor has never spontaneously unmounted a drive.

The RocketStor has some other good points:

I also found some problems:

All of this is to say that I consider the RocketStor a flawed product, but I’m grateful to have it because once a drive is mounted it stays mounted. Sadly that seems to be a lot to ask of a storage product these days.

Update (2014-06-23): There’s a 62-page thread in the Apple support forum about disks ejecting themselves (via Brian P. Hogan).

Update (2015-05-08): The price at Amazon is now down to $147.

CloudKit: Moves Like Azure

Tom Harrington:

CloudKit makes a refreshing change from iCloud Core Data in that there’s a lot less magic going on in the framework. Using iCloud to sync Core Data is very slick, in that you can essentially treat changes from the cloud as if they had been made on a different thread. Changes get saved, you get notified, and you merge those changes and update the app state. Your code never concerns itself directly with the cloud aspects of its data. That’s when it works, of course. It does appear that iCloud with Core Data works much better than it did when I last tangled with it, but it’s still a magic box that abstracts away all of the work of dealing with the cloud.

In contrast CloudKit is not actually a sync mechanism. Instead it’s a transfer mechanism, where your app must explicitly initiate all data transfers. Starting with the CKDatabase class, your app gets local references to cloud-based databases. CloudKit’s API deals with that database as a specifically cloud-based entity. When new changes are available, you need to fetch CKRecord instances and convert them into something that fits your local model. When you have new outgoing changes, you need to create or update the appropriate CKRecord, again converting data as needed.

[…]

As a result, using CloudKit will likely mean more code in your app than using iCloud with Core Data. On the other hand, CloudKit’s more direct and less magical approach to dealing with cloud-based data should be more reliable.

Which Clang Warning Is Generating This Message?

Mattt Thompson:

The problem is that given a warning string, it is very difficult to determine what its corresponding warning flag is. Unless a random Stack Overflow question pops up for the given error string, you’re pretty much out of luck.

So this week, as a public service, we’ve compiled a (mostly) comprehensive list of Clang warning strings and their associated flags[…]

The list is also available at an easy-to-remember domain name.

Update (2018-07-16): It’s now at clangwarnings.com (via Mattt Thompson).

Swift Arrays

David Owens II:

So what’s the real problem here? There are actually two problems that end up causing this issue:

  1. Arrays are structs and structs have value-type semantics. The entire metadata for the array, such as the startIndex, endIndex, and the array buffer pointer all get copied on assignment. This is ripe for bugs, as we have seen above.
  2. Lack of true immutable types.

Update (2014-06-21): Apple will be changing the array semantics.

The Legacy of GOAL

Pål-Kristian Engstad:

In my opinion it was due to one single idea: Interactivity. Think about it: These days we revel in the idea of hot-loading assets, changing shaders on the fly, and interacting via scripting languages such as Lua and advanced level editors. What if your whole engine was interactive. Not just parts of it, but all of it

[…]

Andy’s system was not just a compiler. It was also a linker, a debugger, a dependency manager and a macro expander, but more importantly -- it was a server. This is so fundamentally important. If you are going to change code on the fly, something needs to know “everything”, and the compiler knew everything. It was live, so you could get access to everything, results of macros, memory on the target.

The SSD Endurance Experiment

Lee Hutchinson (via Shawn King):

The results are impressive: the consumer-grade SSDs tested all made it to at least 700TB of writes before failing. Three of the drives have written 1PB (that’s a thousand terabytes, by TechReport’s decimal reckoning, not 1024TB). That’s a hell of a lot more writes than the manufacturers’ stated drive lifetimes, and that’s good news for SSD-buying consumers.

Geoff Gasior:

If you haven’t been following along with our endurance experiment, this introductory article is a good starting point. It spends far more time detailing our test methods and system configurations than the brief primer we’ll provide here.

The premise is straightforward. Flash memory has limited endurance, so we’re writing data to a stack of SSDs to see how much they can take. We’re checking health and performance at regular intervals, and we’re not going to stop until all the drives are dead.