Thursday, 4 September 2014

NetGear ReadyNAS RN102

Been testing RN 102 from NetGear yesterday.

Performance is OK on large files, drops to slow death on smallish files.

Drive caddies are dreadful, especially on removal. When you try to remove the caddy, the caddy slips and the drive remains inside the unit. The retaining mechanism is probably broken by design. It also feels fragile. Earlier models with screws were way more solid, and way more reliable mechanically.

Sunday, 19 January 2014

Storage Spaces again

Came across this, admittedly old, discussion about Storage Spaces

The fun starts at around post #4,with a real good piece of advice - your setting up a large drive system, read a LOT before committing your data to it for good.

Then the discussion touches the Drive Extender briefly. Storage Spaces is not Drive Extender. Indeed it is not. Storage Spaces is arguably more fragile, and undoubtedly Storage Spaces is more difficult to recover once failed. Way more difficult, I'd venture to say.

Then, around post #8, virtual machines come up. The common misconception is that recovery from storage system failures can be practiced with virtual machines. You'd better not. Virtual machines are good for modeling and training some normal operations of a storage system, but they are abysmal in reproducing storage behavior in failures.

In a virtual machine, all hardware is fail-stop. You cannot simulate bad blocks with any fidelity using a virtual machine. The same goes for any kind of hardware problem. Virtual machine cannot not have transient errors of its own. The only situation you can model with a reasonable accuracy is a complete failure of a hard drive (or several of them) on reboot. In real life, you get all kinds of unadulterated hardware problems: timeouts, bad sectors, power transients, defective cables, stuck fans and overheat. At the end of the day, what matters is the response of the storage system to an endless list of real-world, real-hardware problems, and none of these you can reproduce with a virtual machine.

Tuesday, 14 January 2014

RAID rebuild time

Q: Once I have assembled RAID 5 with 5 disks of 1.5 TB in NAS QNAP, disks started to synchronize. 20 hours have passed but only 57% is done. Is this normal? It seems that array works OK (I have already copied data to it)

A: It is typical, especially if the array is also busy with copying data. For large arrays, first synchronization or a full rebuild (after drive replacement) often takes several days. It is advisable not to copy user data to the array until the first synchronization is complete because the array does not still provide redundancy and fault tolerance.

Tuesday, 7 January 2014

Flashing QNAP with disks removed

Q: I pulled the disks out of NAS QNAP to update firmware and then connected them back, but the NAS does not see nor does it initialize them. What should I do?

A: Try to pull the disks out once again, return to the old firmware, and then put the disks back. If it works, try to update firmware without removing the disks. One part of the operating system inside QNAP is stored in the built-in NAS memory while the second part is on disks themselves. Mismatch between these two parts leads to NAS refusal to work with disks.

Tuesday, 31 December 2013

Finding a disk

Q: There are 6 SATA disks in the server. Based on SMART data, one of them (in fourth bay) is going to fail. Someone knows how bays are numbered? Identification by “blinking the bay's LED” does not work.

A: Write down the serial number of the offending disk in the controller configuration tool, turn off the server, pull all the disks out in turn, and find the disk based on the serial number. Then assemble everything back and turn on the server. If everything is OK, turn off the server once again and replace the disk.