[Chris Murphy]

In the realm of otherwise useless and obscure information: Apple’s firmware will boot an OS from a disk with an MBR partition scheme. However the OS X installer will refuse to install to such a disk. In the OP’s case it doesn’t make sense to use MBR though, because as a 32-bit encoded table, he’d only be able to use 2.2TB of the 3TB drive size, so it’s a good idea to use GPT.

[Chris Murphy]

Has the drive died yet? Launch Disk Utility, click on the physical drive (with make/model) and clicking Info. Scroll down and copy-paste all of the SMART related data. Another thing to check is the RAM, boot with the D key. If the utility is built into the firmware it’ll just come up, if not you’ll need one of the DVD’s that came with the Mac. Do the long test and let it run overnight.

I actually don’t know how good that memory test is. On various file system lists I peruse, bad RAM comes up all the time and causes the weirdest transient problems. So that test may be a waste of time because even if it says the memory is good I’d question it. There’s memtest86+ but on most Macs you have to burn a CD/DVD because it isn’t yet ready for EFI firmware, and by putting it on a CD/DVD it’s possible to activate the EFI CSM which emulates BIOS and then memtest86+ will run. It’s a common option with many Linux install media. Just let it run Friday noon until Monday late morning…see if it eventually finds something.

[Chris Murphy]

Eric says journaling adds overhead and can be used to restore (fix) corrupted files (i.e. fix file system inconsistencies). Isn’t he right about that?

Yes, it doesn’t actually work that way. If there were an incomplete file (data) write or it was corrupted when written, the journal wouldn’t have any information to fix either of those problems. Again the purpose of a journal is to (hopefully) obviate the need for a lengthy fsck on larger file systems. Also, since there’s no longer a GUI means of creating a (non-journaled) HFS+ volume for some time, that leaves doing this via CLI which is quite a bit more obscure as a work around for the claim that the existence of a journal causes certain (undefined) issues with applications and controllers; especially when neither apps or controllers are journal aware.

Chris says SAS/SATA controllers aren’t file system aware, they deal with block data. Eric says RAID controllers deal with RAID sets and are responsible for data integrity on them, which could be related to OP’s problems.

The OP’s problem occurs only once two disks in a USB docking station are Apple software RAID 1’d together. This mostly implicates the kernel and by extension the softRAID.kext and one or more of the IOxxx.kext files. So the kernel panic report is needed. Maybe there’s a 3rd party USB driver being used (or not being used) that’s implicated in the kp. But I think it’s very unlikely the kp is journal related at all, and somewhat unlikely it’s drive related. I think it’s more likely related to some hardware incompatibility between XNU and this docking station, for some reason only when software RAID is used.

I did previously say that a kernel panic is always a bug, that’s not entirely true, there are worse things than kp’s which is massive data corruption on disk. So there are some reasons why unhandled exceptions are better ending with the kernel taking an abrupt nose dive rather than staying alive to do possibly some serious damage.

[Chris Murphy]

Re: PDF “Using the HFS+ journal for deleted file recovery” describes a way to use stale journal buffer entries to locate and recover successfully written files that were subsequently deleted, before the relevant journal data itself is overwritten.

That is totally different from the notion that the journal can be “used to restore data that is incomplete or corrupted.” Section 1.3 of the cited document describes rather clearly how journaling of file system metadata only is done by JHFS+. Step 1. only occurs once the file data is successfully committed to disk. The file is neither an incomplete or corrupted file, it’s a successful write. If the write isn’t completely successful, an entry is not made in the metadata journal, there is no point in doing so.

A metadata only journal does not enable restoration of incomplete or corrupted writes to disk. That’s what data journaling can do, and what COW file systems can do (and there are limitations there too depending on when the crash occurs – none of these things enable magical appearance of unwritten data.)

You probably won’t find a document that describes how a controller does not behave but rather how it does. There are a lot of things a controller does, but file system management and mounting isn’t one of them. The controller manages the physical, link and transport layers to the drive which includes 8b/10b encoding, NCQ/TCQ, FIS, things that the OS does not need to deal with. The payload in FIS packets is the data stored on the disk sectors, and that raw data can be bootloader code, partition maps, file system structures, file metadata or file data itself. Neither the drive nor controller care what the payload is.

For hardware RAID cards, there’s an additional layer because they’re necessarily a bit more intelligent. Depending on the implementation, they might understand what a partition map is, and they’ll certainly understand their own raid metadata found on each drive which enables them to know what chunks are on what physical drives, and what the LBA mappings are. Many hardware controllers work directly on unpartitioned disks, writing only its particular flavor of raid metadata to manufacturer defined locations on each disk. Assembling the raid array (a logical block device) is the job of the controller, and presents that logical block device to the kernel via a kernel driver; the kernel sees this block device as it does any physical block device (like a bare drive). Obviously there is no such thing as a 12TB physical block device (yet), but the kernel doesn’t know that and doesn’t need to. Like with any drive, it asks the controller to read at least LBAs 0,1,2 which are the standard locations for the pMBR, primary GPT header and GPT table. The raid controller maps those requests to their actual physical devices and LBAs – meaning that this partition data, contained within the logical block device, is subject to being stored in both a data chunk and parity chunk just like any other kind of data.

The kernel then parses the GPT, finds a partition type GUID it recognizes, finds the start LBA for that partition, asks the controller to read e.g. LBAstart+2 which is the location for the JHFS+ volume header. Naturally this is different for each file system. The controller fullfills that request by sending a read LBA request to the proper physical drive. The kernel, from the volume header data, can then find the various other JHFS+ structures, request those LBAs from the controller, which in turn maps those requests to actual physical drives, and once the kernel has sufficient information about the volume the volume is mounted and presented in a sequence of events that also involves diskarbitrationd and the Finder.

So there are lots of layers, and you’re not going to find things parsing data in layers it doesn’t need to. Neither SAS, SATA, or RAID controllers need to understand file system structures at all and have nothing to do with mounting a file system. SATA/SAS controllers present a physical block device to the kernel, and raid controllers assemble physical member disks into a logical block device and present that to the kernel. RAID array assembly, and volume (file system) mounting are different things.

[Chris Murphy]

“journal is used to restore”

JHFS+ uses metadata only journalling, data journaling does not happen. The kb statement above means the journal is used to update the state of the file system, rather than having to run fsck. If at mount time the journal is determined to be inconsistent, then fsck is needed.

“It’s also used to restore data that is incomplete or corrupted on the drive.”

This is incorrect.

As for the “meta data issues” with journaling, what issues? You’ve established only correlation to journaling, not causation. NTFS is also a journaled file system, do these same problems happen with Windows applications on NTFS? Or only with 3rd party software on JHFS+? And since at least 10.8, possibly 10.7, Disk Utility doesn’t have an option for HFS+ anymore. It only creates JHFS+ and HFSX, with or without encryption. There also isn’t an option to disable the journal on an existing JHFS+ volume. This can still be done with CLI using diskutil disableJournal. It’s much more difficult to disable it on NTFS. Journaling has been around for a really long time, for apps to have a problem with it sounds like an application bug.

Also, SATA/SAS controllers don’t understand file systems, journals, or even partition schemes. They don’t understand any of the data on a hard drive. Their job strictly to communicate with the drive and manage the stream between kernel and drive. Controllers don’t mount file systems. The job of mounting file systems and understanding their structures is with the kernel, and only the kernel and certain file system utilities should care about the existence (or not) of a file system journal.

[Chris Murphy]

I can’t speak to MSS, but I can the other three. None by themselves mitigate the consequences of the WDC Green’s high SCT ERC timeout. RAIDZ can of course detect errors that the drive cannot, but before ZFS (or Btrfs or ReFS) kick in with their own ECC, the drive ECC is in charge. When it encounters a problem, it will attempt error recovery itself for up to 2 minutes before it sends the data to the controller. If you’re lucky, the drive errors out much sooner and ZFS can then correct for that, as can the linux md driver. But likewise, the md driver can’t work around the high time out either. It simply must wait. The linux SCSI layer by default has a lower timeout than these drives (as do many hardware raid controllers), so if the SCSI layer timeout is reached before the drive timeout, the drive is reset. The drive then can’t report a read error or what sector was experiencing a problem to the kernel, and thus it isn’t fixed by either RAIDZ or the md driver.

With some luck, the drive errors out sooner, and then either ZFS or the md driver will receive the read error from the drive which includes the sector LBA, and the data can be reconstructed from parity, handed off upstream to your application and downstream back to the drive to overwrite the bad sector. This is far less certain and common when the drive has high ERC timeouts though. And that timeout isn’t configurable on the Green. Regular scrubs are likewise adversely impacted by the high ERC timeout of the drive. The timeout is critical to getting the correct data for the bad sector and causing it to be overwritten.

As for Drobo, well, I think it’s weird they’d want to support something that WDC themselves do not. And after Scott Kelby Drobo Experience, I wouldn’t trust it for photos let alone video I cared about, regardless of the drive it uses.

Now, I’ll grant that using a Green drive in raid can be done, and can work, but with such huge PITA caveats that it’s just not worth it in the likely context of this forum. Google, Amazon, I don’t know if they use these drives, but they do use consumer drives for certain use cases, I wouldn’t be surprised if they get a great deal for a DOA only warranty. But they also use distributed file systems. So they can lose not just a whole array, not just a whole rack of storage, but an entire data center, and keep plugging along. They don’t use distributed file systems to mitigate using cheapo drives. They use cheapo drives in some cases because they have a distributed file system in place for many reasons other than storage failure mitigation. And when Google have problems with this system the delays aren’t just a few seconds, so I’m skeptical if it’s adequate enough for the demands of video work.

A mere mortal could pre-emptively mitigate bad sectors by periodically zeroing (or writing anything, or even faster would be to use ATA Security Erase) the drive which will force the firmware to remove any sectors with persistent write failures; and also doing a weekly SMART extended offline test using smartmontools. Both probably qualify as PITA for most people. And then, moving data around to free up drives for their regular wiping, there’s the increased risk getting hit with silent data corruption.

So yes, USB stick raid is probably more ridiculous than using Green drives in raid. But compostable pistachio shell water filters are a better idea.

[Chris Murphy]

USB stick RAID can be used where differences in their behavior is either irrelevant or well mitigated.

If you have a mitigation example for using Green drives in raid, that might be a useful qualification.

Even at a 50% premium for Red vs Green, the Green’s warranty is invalidated by using it in any raid, so is that really worth 1/2 off, in addition to having the wrong ERC timeout?

Yes I did notice the OPs problem wasn’t related to the use of Green drives, because his thread update was in reply to my belated comment, in which I didn’t focus on Green drives being the culprit.

[Chris Murphy]

Yes, there are also smart ways to use a pistachio shell as a water filter.

So you aren’t using or recommending Green’s, and yet in the previous post your two questions insinuate that either the difference in firmware behavior is unimportant/meaningless, or that somehow WDC is acting immorally by charging more for different firmware behavior. And you’re also discounting the 3 year versus 2 year warranty, and the fact that the Green’s 2 year warranty is technically invalid per the marketing spec sheet if you use it in raid. So it’s a three year versus 0 year warranty, for a $22 difference. And you think this is sticking it to the man. Yes I have read your post and the point escapes me, other than something in between “ill advised” and “rather tedious to mitigate”, can still be done. Actually the pistachio shell as a water filter makes vastly more sense, at least it’s compostable.

Meanwhile I’m informed off-list that bin sorting is not used for mechanical drives. So it seems more likely there is in fact a physical difference between Green and Red models, no matter how similar they look from the outside or on paper. Obviously WDC trusts the Reds for an additional year of usage on top of the fact it’s qualified for 24×7 use and the Green is not.

[Chris Murphy]

Newegg.com
WDC Red 2TB = $119
WDC Green 2TB =$109

WDC Red 3TB = $150
WDC Green 3TB =$128

It’s $10 and $22 respectively. Most people are going to save a couple hundred bucks. At least Murray has “saved” in the realm of $2k-5k, but I think they’re going to end up being more hassle than they’re worth.

But if you look at the specs, they match up very much the same, although the power consumption and acoustics are slightly different and I doubt that comes from firmware alone. If they are identical, WDC could be sorting them based on test performance data after assembly, before labeling and setting a key in firmware that makes the drive behave according to its model. So it might even be the same firmware. The real question is, why does it matter?

Back in the late 90’s I consulted with a TV station about to supplement their quantel’s with a Mac based video editing station. I can’t for the life of me remember the company/brand, but what I do remember is the various products were in fact a single software and hardware base, with feature sets unlocked by firmware in the hardware card and a serial number (or possibly a dongle) for the software. The difference in price was in the realm of $5000 for the low end and $30,000 for what the customer ended up buying. Same hardware and software installed, enabled by firmware and a code.

Today I work primarily in color management and the same thing is common, you get identical hardware, but features are unlocked depending on what you paid for, all of it being dongle protected.

And this was extended several years ago to CPUs. Intel disables some of the cache and the cores and sells those chips as a different brand (Core i7) than the ones with all cores and cache enabled (Xeon). You get what you paid for.

So I don’t see why it matters. You want to save $10-50 and get the exact wrong firmware behavior? Good luck with that, but I don’t see it as sticking it to the man when you make that choice, you’re sticking it to yourself.

[Chris Murphy]

I didn’t take it as a stab, and even if it did I’m fairly immune. I think the issue you’re likely to see is marginally bad sectors creeping in that aren’t detected during normal or scrub operations because the drive firmware is designed to mask such problems. The point at which they’re unrecoverable is when the drive times out and finally reports a read error. And only on a read error can the controller rebuild the affected chunk from parity and cause the bad sector to be overwritten, at which point the firmware will determine if the bad sector is transient (it just needed to be rewritten) or if it’s persistent, and if it is persistent then the firmware will remap the LBA(s) to a reserve sector and write the data. The ability for parity raid to “self-heal” in normal read operations and in scrubs in the described manner is thwarted with Green drives. The use case and design goal are incongruent, and that is what technically nullifies the warranty.

With ~300TB of Green drives I think you’ll see untimely collapse of an array rather than the normal degrade and rebuild. With this many drives the proper drive from WDC is the Se. Even the Red is limited to 5 drives per array so if you’re over that, technically they could deny warranty because of the use case and design goals aren’t compatible. They say this rather plainly on the marketing spec sheet.

So that’s the extra long version of what “impossible” and “worst idea ever” probably translate into.

Also note that the WDC Blue and Black also are not meant for anything other than raid0 or 1. The first applicable drive is the Red, but that’s for 5 or fewer disk arrays. More than that and it’s the Se.