Administrace komentářů

Některé RAID řadiče (myslím, že podobně postupovaly i některé NASy co připouštěly osazení "desktop-ready" HDD) se s takovou situací patrně uměly vypořádat a v případě, že vrácení dat trvalo neúměrně dlouho tento HDD označily jako nefunkční a s dalšími požadavky se na něj již neobracely. Na toto chování se myslím nelze spoléhat u SW-based storage při využití systémových SATA či HBA řadiče. Tam musí být HDD správně chybný, aby při opakovaném selhání nedocházelo k neuměrnému timeoutu (nevzpomínám si zda mdadm má nějakou automatickou policy pro vyřazení takového memberu). Možnost zrušit předem timeout je asi dostatečnou alernativou, pokud nejde o systémový volume a k vícečetnému timeoutu dojde ještě před samotným zrušením timeoutu.

Už je to přes čtvrt století kdy jsem spravoval svůj první "RAID" (mirror) na Novell Netware 3.11, který jestli si vzpomínám správně měl v rámci mirror struktury několik % z kapacity vyhrazenu tzv. HotFix area, do které realokoval na úrovni mirroru obsah v místě chybných sektorů, takže zajistil po chybě okamžitě redundanci na stávajících HDD. Přemýšlím zda v roce 1993 vůbec měly (v tomto případě SCSI HDD) již automatickou interní realokaci chybných sektorů. Každopádně Netware zajistil, že validní (čitelná) hodnota z druhého člena byla opět dostupná na obou členech (na jiném části HDD). V té tobě možné ještě Verify bylo opravdu znamenalo verify a bylo možné ověřovat úspěšnost samotného zápisu.