FORUMS: list search recent posts

External hard drive(s) causing Kernel Panic since RAID setup.

COW Forums : RAID Set-Up

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
Luke Ogden
External hard drive(s) causing Kernel Panic since RAID setup.
on Aug 12, 2013 at 2:02:32 pm

Hi all,

I recently tried setting up a RAID 1 mirrored set of drives to use as an archive for my video work, I used two brand new 3TB Seagate Baracuda SATA drives plugged 'bare' into a Startech dock
http://uk.startech.com/HDD/Docking/~SATDOCK2U3GB

despite being brand new I formatted each drive in disk utility to extended (journaled) using the secure 'zero out data' option (it took 1.5 days per drive!), and had them both mounted.

It was when I was subsequently setting the two newly formatted drives up as slices of RAID 1 Mirrored set in Disk Utility that I got Kernel Panic.

Now whenever I plug the drive(s) into the dock they don't mount and I get the Kernel.

There don't appear to be any drivers for the dock available and my software is up to date, computer specs in the signature.

27" iMac 3.4 GHz Intel Core i7, 16GB 1333 MHz DDR3, OS X 10.7.5 //


Return to posts index

Eric Hansen
Re: External hard drive(s) causing Kernel Panic since RAID setup.
on Aug 12, 2013 at 3:37:39 pm

I've never used that particular dock, but I have had issues when trying to run multiple drives over a single USB3 connection. A client gave me an 8 drive enclosure where each drive was its own volume. So 8 drives would appear on my desktop when connected. But it was unreliable. Not sure if it was individual drives spinning down, something with USB3 or something with the controller in the enclosure. But it was most reliable if i pulled each drive out of the enclosure (just an inch so they could still sit in there, but not be connected) and just access one drive at a time. This was on a 15" rMBP

e

Eric Hansen
Production Workflow Designer / Consultant / Colorist / DIT
http://www.erichansen.tv


Return to posts index

Alex Gerulaitis
Re: External hard drive(s) causing Kernel Panic since RAID setup.
on Aug 12, 2013 at 7:21:04 pm

Eric has a good point, accessing drives one by one. Tried putting just one drive in?

Any way to try the drives in a different system?


Return to posts index


Luke Ogden
Re: External hard drive(s) causing Kernel Panic since RAID setup.
on Aug 12, 2013 at 11:28:31 pm

Tried accessing the drives using the dock connected to my rMBP, Which also caused a kernel panic as does accessing the drives one at a time. It's surprising because the drives where reliable and docked simultaneously for 3+ days whilst formatting but now I cant get them to stay mounted for two minutes without the panic.

27" iMac 3.4 GHz Intel Core i7, 16GB 1333 MHz DDR3, OS X 10.7.5 //


Return to posts index

Bob Zelin
Re: External hard drive(s) causing Kernel Panic since RAID setup.
on Aug 13, 2013 at 10:15:32 pm

you should not have done a low level format (zeroing out the data).
That's all nonsense.

You can get a free replacement on the drives from any manufacturer (you are in warrantee) and do it again, but don't do a low level format. This ain't brain surgery.

Bob Zelin

Bob Zelin
Rescue 1, Inc.
maxavid@cfl.rr.com


Return to posts index

Kylee Peña
Re: External hard drive(s) causing Kernel Panic since RAID setup.
on Aug 13, 2013 at 10:28:38 pm

Bob, if I may ask a half-related question, is zero out data always nonsense or just in this case? Just curious.

blog: kyleesportfolio.com/blog
twitter: @kyl33t
demo: kyleewall.com


Return to posts index


Bob Zelin
Re: External hard drive(s) causing Kernel Panic since RAID setup.
on Aug 14, 2013 at 12:37:57 pm

to my knowledge, there is absolutely no reason to zero out data, or do a low level format on a disk drive (SATA, SAS, SCSI, SSD), unless you are trying to get rid of kiddie porn evidence on your drive. A simple quick format on a WinPC or re-partition or erase on a Mac is all that you need to do. I have not looked at spec sheets from WD, HGST and Seagate for some time now, but I recall some type of statement to not do a low level format on the drives from (at least one) of these manufacturers. So yes, it's always nonsense. The same nonsense when people say "never turn off your RAID array".

Bob Zelin

Bob Zelin
Rescue 1, Inc.
maxavid@cfl.rr.com


Return to posts index

Bob Zelin
Re: External hard drive(s) causing Kernel Panic since RAID setup.
on Aug 14, 2013 at 12:44:59 pm

https://discussions.apple.com/thread/5105956?start=0&tstart=0

good recent thread on this subject.

Bob Zelin

Bob Zelin
Rescue 1, Inc.
maxavid@cfl.rr.com


Return to posts index

Eric Hansen
Re: External hard drive(s) causing Kernel Panic since RAID setup.
on Aug 14, 2013 at 3:38:54 pm

I read somewhere (and of course I don't remember where), that drive manufacturers are no longer taking the time to scan and map out bad blocks before shipping. This somewhat explains the linked recommendations from Seagate in that Apple Discussions Thread.

I try to use something like DiglloydTools "Fill Volume" on new drives before I send them out into the field. But of course, I never seem to get the time :)

e

Eric Hansen
Production Workflow Designer / Consultant / Colorist / DIT
http://www.erichansen.tv


Return to posts index


Chris Murphy
Re: External hard drive(s) causing Kernel Panic since RAID setup.
on Aug 18, 2013 at 8:12:40 pm

Even if true, the read-write head is designed such that writes are immediately followed by reads, and the firmware confirms/denies the write. If it persistently fails for a sector, the LBAs are reassigned to a reserve sector(s) and the bad sector is removed from use. It can't even be accessed by software anymore as it no longer has an LBA. Writing zero's will also do this. But it's not really necessary in advance.

The bigger issue for large raid arrays is the lack of scheduled scrubbing, to make sure rarely read/written sectors aren't going bad. The typical case of raid5 array failure is lack of scrubbing, a handful of bad sectors are developing on one or more drives, and a single drive failure occurs. During rebuild, one of those bad sectors is encountered as a persistent read failure and the rebuild fails and thus the array fails. It's also exacerbated by using consumer drives with very long error correction timeouts.

Before disposing of a drive, it's probably a good idea to "clear" or "purge" any non-raid, or raid1 drives; just like it's a good idea for photographers to tear their reject prints before disposing of them. "Clear" is the minimum kind of erase, which is what Apple Disk Utility uses. To constitute "purge" one must use the firmware's ATA Secure Erase, Sanitize or Crypto Erase commands. Even though ATA Secure Erase has been in ATA drives since 2000, Apple sadly doesn't support it in Disk Utility, and is the only way to sanitize data that exists in bad blocks removed from use that still contain data. The added thoroughness is perhaps a small benefit, but using ATA commands to have the firmware perform the operation is much faster than writing zeros sector by sector by software. And it also entirely frees the bus from write operations. Further annoying is that most USB bridge chipsets don't support the passthrough needed for these commands to work so typically it's only available with a SATA or eSATA connection.


Return to posts index

Chris Murphy
Re: External hard drive(s) causing Kernel Panic since RAID setup.
on Aug 18, 2013 at 7:32:18 pm

Zeroing the drives can't possibly be related to the problem. It may be pointless, but it's also benign. He had over ~750 million successful write operations doing that zeroing, and only once the raid1 was created did he start getting kp's. So I think the problem is elsewhere.

If he can get one drive into either the existing docking station, or an alternate enclosure, without getting a kp; or booting a totally different kernel that doesn't panic with this hardware, it's possible to remove the Apple raid1 metadata from both drives, and then see if the kp is consistently reproducible only when the drives are software raid1'd together. That's much faster than returning the drives. And to save time he needs to know if this is induced by software raid1. I think it's some obscure incompatibility between software raid1 and this docking station, but there isn't enough information to know that yet.


Return to posts index

EricBowen
Re: External hard drive(s) causing Kernel Panic since RAID setup.
on Aug 14, 2013 at 6:30:14 pm

Can you access the drives in Disk utility long enough to format them HFS+ Non Journaled? Do you have a Windows system available that you can run a clean command on if not?

Eric-ADK
Tech Manager


Return to posts index


Luke Ogden
Re: External hard drive(s) causing Kernel Panic since RAID setup.
on Aug 14, 2013 at 9:52:46 pm

Interesting, there seems to be quite a few of conflicting ideas and the subject; some new and old school thought.

Ok I'll try get the drives mounted on a window system long enough to re-format the drives, although I'm a bit freaked out now so may just send them back.

27" iMac 3.4 GHz Intel Core i7, 16GB 1333 MHz DDR3, OS X 10.7.5 //


Return to posts index

EricBowen
Re: External hard drive(s) causing Kernel Panic since RAID setup.
on Aug 14, 2013 at 10:01:14 pm

Don't format the drives on the Windows system. Just get into the Diskpart utility and run the clean command. That will wipe the disk table info. Then you should be able to initialize and format them again on the Mac. Just don't use Journaling. Journaling add's allot of meta data that has and can cause problems with applications and I would not be surprised causing some issues now with the controller. Journaling is used for HFS+ partition data recovery. Other than that it has no other real function. I am proponent of writing zeros to drives to clean them out since it seems the drive manufacturers are not marking the bad blocks out before they ship them anymore. The link above from Apple's forums has a post from the drive manufacturers as to why they suggest it also. I don't believe you were wrong in that nor do I think that caused this issue because it shouldn't have.

BTW you will probably have to install Mac Drive trial long enough to recognize the disks in Windows to clean them. An other option is to download Acronis or Paragon Software's boot disk and boot to the utility. Then Delete the current partition. Then boot to Windows and clean the drives. I figure one of the 2 boot discs should boot on an IMac. If not Boot on the Windows system with the boot discs

Eric-ADK
Tech Manager


Return to posts index

Eric Hansen
Re: External hard drive(s) causing Kernel Panic since RAID setup.
on Aug 14, 2013 at 10:05:45 pm

once i have properly set up a drive, if it gives me issues even once and it's still under warranty, i send it off for replacement. i don't have time to mess around and my data's too important. i use Hitachi because they have a no questions asked replacement policy, but i bet other companies do too.

e

Eric Hansen
Production Workflow Designer / Consultant / Colorist / DIT
http://www.erichansen.tv


Return to posts index

Chris Murphy
Re: External hard drive(s) causing Kernel Panic since RAID setup.
on Aug 19, 2013 at 3:35:25 am

The journal makes it possible to mount an unclean file system faster than doing a full fsck, not data recovery. On large volumes, or with many files, an fsck on a non-journaled file system can take a long time, even hours, and gobs of memory. The journal has no possible relationship with application problems, they aren't even aware of the journal being enabled or not. There is perhaps some advantage to disabling journaling on SSDs, which can repair much faster in the event of an abrupt unclean unmount, and also the journal writing a lot of metadata will cause additional SSD wear. But if this is for video, there isn't much metadata anyway. The file sizes are huge, and quantity few, therefore not much metadata.


Return to posts index

EricBowen
Re: External hard drive(s) causing Kernel Panic since RAID setup.
on Aug 20, 2013 at 3:19:32 pm

http://support.apple.com/kb/HT2355

"When you enable journaling on a disk, a continuous record of changes to files on the disk is maintained in the journal. If your computer stops because of a power failure or some other issue, the journal is used to restore the disk to a known-good state when the server restarts."

Notice the Restore in this part? File system integrity data is not just used for verification. It's also used to restore data that is incomplete or corrupted on the drive. Hence what I stated. And yes there have been meta data issues with the Journaling especially on the Windows platform with Mac Drive because the application is not communicating with the drive directly. It is through the hardware controller. That translation of Volume to block data has to go through that process and that is where the problems happen. Verified here with turning Jounaling off and has often been recommended for Mac based formatted drives used for processing work and not archive.

BTW if the controller cannot recognize the volume table or data it wont initialize and mount the disks which is what this issue is pointing to.

Eric-ADK
Tech Manager


Return to posts index

Chris Murphy
Re: External hard drive(s) causing Kernel Panic since RAID setup.
on Aug 20, 2013 at 5:36:20 pm

"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.


Return to posts index

EricBowen
Re: External hard drive(s) causing Kernel Panic since RAID setup.
on Aug 20, 2013 at 7:39:54 pm

http://www.dfrws.org/2008/proceedings/p76-burghardt.pdf

I have yet to find any whitepaper or information that does not state the controller is not translating instructions from the processor or OS/application. If you have references otherwise please link them. BTW a Raid Controller wont Mount the Raid volume without a OS kernel?

Eric-ADK
Tech Manager


Return to posts index

Alex Gerulaitis
Re: External hard drive(s) causing Kernel Panic since RAID setup.
on Aug 20, 2013 at 8:09:41 pm

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?

Chris says journaling in itself is not a backup/restore mechanism as it doesn't save actual file contents, only metadata. Does this conflict anything Eric said?

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.

Are there really any conflicts between what you two are saying?


Return to posts index

Chris Murphy
Re: External hard drive(s) causing Kernel Panic since RAID setup.
on Aug 20, 2013 at 10:53:44 pm

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.


Return to posts index

Chris Murphy
Re: External hard drive(s) causing Kernel Panic since RAID setup.
on Aug 20, 2013 at 9:52:00 pm

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.


Return to posts index

Chris Murphy
Re: External hard drive(s) causing Kernel Panic since RAID setup.
on Aug 18, 2013 at 7:25:49 pm

So the kernel panic only happened after creating a software raid1 array? And the drive erase operation that took three days was successful for both drives?

Certainly any kp is a kernel bug, but it can be triggered by wrong hardware behaviors. Yet ~750 million write operations were successful during the erase. Can you post the kernel panic to pastebin and post the URL in the forum?

It's a good idea to allow the system to report the kernel panic to Apple, and in the comment section including the make/model and firmware revision of the docking station, and the condition that the kp's started to happen only after two drives were software raid1'd together. That could be coincidence, the only way to test this would be to work with drives that don't have Apple raid metadata on them, and see if they can be used independently for a while. Then recreate the software raid1 and see if you get kp's again.

Do you get a kp when only one of the drives is inserted into the docking station? If not, the Apple raid metadata can be remove from OS X using dd. If it does still kp, then either you'll need to put the drive into a alternate enclosure which hopefully doesn't trigger the kp. Or boot the iMac from a Linux live cd/dvd and use dd there to wipe the raid metadata off the drives. So decide which is easier: downloading and booting from a linux live cd/dvd or swapping enclosures. And then once you confirm you're not getting kp's when connecting a single drive post the result from this command:

diskutil list

And I'll get you a suitable dd command to blow away the Apple software raid metadata.


Return to posts index

Luke Ogden
Re: External hard drive(s) causing Kernel Panic since RAID setup.
on Aug 30, 2013 at 12:02:40 pm

[Chris Murphy] "So the kernel panic only happened after creating a software raid1 array? And the drive erase operation that took three days was successful for both drives?"

Correct.

[Chris Murphy] "Can you post the kernel panic to pastebin and post the URL in the forum?"

http://pastebin.com/zJph9DqA

[Chris Murphy] "Do you get a kp when only one of the drives is inserted into the docking station?"

Yes I tried mounting them one at a time and they cause a kp individually as well

UPDATE
I'm been away for a few weeks but this morning I successfully mounted each drive long enough to format to Mac OS Extended (journaled) in disk utility.

They are currently both mounted in the dock and I've been performing a few basic read/write functions to each.

I'm about to try setting them up as a RAID 1 pair again using the 'best practice' ie. don't zero out the data and format each as Mac OS Extended (Journaled), correct ?

If I configure them as RAID 1 again and get the kp we know its the dock don't we?


Return to posts index

Chris Murphy
Re: External hard drive(s) causing Kernel Panic since RAID setup.
on Aug 30, 2013 at 6:13:52 pm

don't zero out the data and format each as Mac OS Extended (Journaled), correct ?

Yes. Zeroing isn't needed, diskutil should wipe the metadata areas first, and then create new ones, then format the resulting logical block device as HFSJ. It shouldn't matter what the file system is, the kp appears to be occurring before the file system is mounted, at the time the raid is being assembled.

If I configure them as RAID 1 again and get the kp we know its the dock don't we?

Your kp report points to two things that were in use immediately prior to the kernel panic: apple.iokit.IOStorageFamily and apple.driver.AppleRAID. And in the list of loaded kexts, I see only Apple kexts. I think it's a kernel bug. It may also be that the dock isn't conforming to some aspect of the USB spec, and the kernel isn't prepared to handle it. Or maybe something is being corrupted (again could be dock firmware related) and the kp is occurring as the result of reading some corrupt metdata.

But in any case, the protocol is to treat it as a product defect with the manufacturer. They need to confirm/deny whether they support Apple software RAID 1 being used with their product (I haven't looked at whether they claim this in marketing material or spec sheets). And if they want to support it, they need to take it up with Apple to work out the details of who fixes what.

I suspect you will get another kp, because a non-deterministic bug where you don't is actually worse. Without a lot of usage you won't have confidence if at any future time you will get another kp. And that could cause raid metadata corruption, or worse, file system corruption. So I think that's not really worth messing around with, I'd go straight to the manufacturer, see what their expectations are for its use. If it's supposed to work with software RAID, have them swap out the hardware.

Another thing you could try is a much newer kernel. Current is XNU 12.4.0 which is the OS X 10.8.4 kernel. It's possible the manufacturer will recommend this too. I haven't check the specs to see what the minimum supported OS is.


Return to posts index

Chris Murphy
Re: External hard drive(s) causing Kernel Panic since RAID setup.
on Aug 30, 2013 at 6:26:16 pm

Attempt 2 at being more concise and coherent on next steps. What *I* would do is not even mess with the dock anymore. I would call the manufacturer support, tell them you used Apple software raid1 with Disk Utility, and now you're getting kernel panics on both a rMBP and iMac. And you're happy to give them the kp report if they want. Questions for them: Is the use of Apple software raid1 supported with this dock, i.e. is it expected to work? Is it expected to work with OS X 10.7.5? Do I have the current dock firmware applied (if applicable)?

If the answers are yes, yes and yes. Then set up an RMA and send it back. I wouldn't try to troubleshoot this specific unit anymore. All of the conditions are the same as before, so just trying again shouldn't matter and if it does matter, it's still unreliable. So I'd swap out the hardware.


Return to posts index

Luke Ogden
Re: External hard drive(s) causing Kernel Panic since RAID setup.
on Sep 12, 2013 at 12:35:23 pm

So I spoke with Startech, the manufacturer of the dock today and there technical advisor informed me that this particular dock doesn't support Apple RAID 1 software configuration. So as you rightly suggested Chris I'm going to swap out the hardware and start over. Thanks for the help in troubleshooting this problem.

With regards the new hardware has anyone any recommendations? The technical advisor pointed me in the direction of this enclosure

http://uk.startech.com/HDD/Enclosures/Dual-Bay-SATA-External-Hard-Drive-Enc...

But as its for weekly backups I kind of liked the tool-less design of the previous dock. Not a deal breaker though, As this will be the third solution I will have purchased It's important now to just get something that works.

Thanks


Return to posts index

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
© 2017 CreativeCOW.net All Rights Reserved
[TOP]