Saturday, 4 October 2014

Entropy analysis

This one is the most perfect example of entropy analysis I've seen done with ReclaiMe Pro to date


This one features three distinct frequencies. Think of entropy analyzer as of oscilloscope, giving you wavelength (inverse frequency) and phase. Block size is wavelength and block start offset is phase.

So there are three distinct wavelengths (block sizes)
  1. 16KB block of parity,
  2. 4KB filesystem (NTFS) cluster
  3. 1KB NTFS MFT entry size

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 http://www.eightforums.com/general-support/15887-storage-spaces-questions.html

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.