AMD integrerer RAID-brikke fra Dot Hill

[ATWindsor]

Vil ikke de fleste kontrollere bare stoppe rebuild hvis du får en URE ved RAID 5 rebuild? Det er det eneste fornuftige. I praksis betyr det vel at en må gjøre en restore uansett. Sjelden at manuell fiksing av slike feil er tilstrekkelig da det er utfordrende å restore en enkelt RAID stripe fra backup.. mildt sagt.

 

Jeg ser ikke helt hvordan det kan være mindre drastisk at hele arrayet går ned enn at det er i en ukjent og ufullstendig status, men garantert feil i minst en stripe. En må like fullt gjøre en restore.

 

Jeg har ikke så veldig god kjennskap til hva andre kontrollere gjør, men såvidt meg bekjent så gjør ikke min kontroller det. Ikke skjønner jeg at det er det enste fornuftige heller. Å logge at det er en URE i rebuildinga og varsle om det er jo uansetlig mye mer fornuftig, for om noe er galt med restoren, så ligger man bedre ann. I praksis manifisterer det seg jo gjerne med at en fil er ødelagt, noe som er vesentlig bedre enn alternativet (personlig checkusmmer jeg feks mange av mine viktigste filer, da kan man ganske raskt oppdage det også), og jeg ser ingen fordeler med at kontrolleren nekter å rebuilde.

 

AtW

[G]

RAID 5 er i ferd med å bli erstattet med RAID 6 i bedrifter. RAID 5 er ikke sikkert nok. Har du et 12TB RAID 5 på hyllevare SATA disk så har du ca 50% sjanse for å få til en rebuild. Avanserte kontrollere med patrol read og write verify samt dyrere disker kan mothjelpe dette. Uansett er nok ZFS og BtrFS fremtiden for store arrays. De mye mer pålitelige enn noen RAID kontroller "by design", blandt annet er ZFS og BtrFS immune mot RAID 5 write hole.

Jeg er ganske tom for kunnskap i dette fagfeltet. Men la merke til følgende 2 ting når jeg slo opp ZFS:

ZFS has no defragmentation utility. Usage of COW with often changed files leads to high fragmentation.

 

Nå er kanskje ikke Linux det primære målet for ZFS-bruk, men..

Linux

 

Porting ZFS to Linux is complicated by the fact that the GNU General Public License, which governs the Linux kernel, is incompatible with the Sun CDDL under which ZFS is distributed. A single derived work of both projects cannot be legally distributed, as it is not possible to simultaneously meet both licenses' requirements. To include ZFS in the Linux kernel it would have to be cleanly reimplemented, and patents may hamper this.[43]

 

The solution to this problem was to port ZFS to Linux's FUSE system so the filesystem runs in userspace instead, where it is not considered a derived work of the kernel. A project to do this was sponsored by Google's Summer of Code program in 2006, and is in a bugfix-only state as of March 2009.[44] The original ZFS on FUSE project is available here. Sun Microsystems has stated that a Linux port is being investigated.[45] Development for ZFS on FUSE/Linux now takes place at zfs-fuse.net.

Endret 1. mars 2010 av G

[Anders Jensen]

Defragmentering til ZFS og BtrFS kommer nok med tiden. Det er en nødvendighet på COW. ZFS på linux vil nok aldri bli det helt store pga lisenstrøbbel. BtrFS har riktig lisensiering for Linux og er på sett og vis en litt mer ambisiøs versjon av ZFS. Nå er vel ikke linux å foretrekke til filserving uansett. Solaris, opensolaris og FreeBSD er mye bedre til det IMHO.

[ATWindsor]

ZFS er jo et ganske suverent filsystem, og såvidt jeg kan bedømme vesentlig mer sikkert enn RAID. Er faktisk selv i prossen med å oppgradere Backupserveren min til ZFS (kjører hardware-raid per i dag), men venter på 2010.03-versjonen av opensolaris. BtrFS er jo også veldig interessant, men synes det virker som utviklingen går litt trått der.

 

AtW

[Anders Jensen]

BtrFS ligger noen år etter ZFS i løypa, men har en modifisert b-tre struktur som er potensielt kraftigere enn den binær tre strukturen brukt i ZFS. Utover det er de vel i prinsippet ganske like, men ZFS har langt flere egenskaper implementert og er naturlig nok mer stabil på dette tidspunkt.

 

Når det gjelder rebuilding av RAID 5 uten avbrudd ved URE så blir det grunnleggende problemet å finne ut hvilke(n) fil som er korrupt. Uten å vite det er eneste alternativ full restore i de fleste praktiske tilfeller.

[ATWindsor]

BtrFS ligger noen år etter ZFS i løypa, men har en modifisert b-tre struktur som er potensielt kraftigere enn den binær tre strukturen brukt i ZFS. Utover det er de vel i prinsippet ganske like, men ZFS har langt flere egenskaper implementert og er naturlig nok mer stabil på dette tidspunkt.

 

Når det gjelder rebuilding av RAID 5 uten avbrudd ved URE så blir det grunnleggende problemet å finne ut hvilke(n) fil som er korrupt. Uten å vite det er eneste alternativ full restore i de fleste praktiske tilfeller.

 

Joda, det er fett nok at for mange er full restore eneste alternativ, men dette fordrer at systemene er oppe som de skal, og det er det ikke alltid de er. Det gir ingen mening å bare kaste hele raidet på båten ved enhver liten feil, sålenge det varlses om at det er en URE, kan de som har mulighet og ønske om å kjøre full restore gjøre det, mens de som har uffullstendige backuprutiner, viktige filer som er helt nye eller av andre grunner ikke kan kjøre restore på alt har faktisk en mulighet til å få raidet opp igjen, og store deler av filene inntakt.

 

AtW

[G]

Nå er jeg ikke sikker på om kildene gir ett riktig bilde her. Men kom nylig over denne blog'en om problemer med Microsoft som børsprogramvare hos London Stock Exchange. Hvor bloggeren hevder at det ville gått mye bedre med Linux. :!:

 

http://realitylenses.blogspot.com/2009/07/lse-microsoft-what-was-ment-to-happen.html

 

So, might I suggest to the LSE that they consider Linux as the foundation for their next stock software infrastructure? After all, besides working well for Chi-X, Linux seems to be doing quite nicely for the CME (Chicago Mercantile Exchange), the NYSE (New York Stock Exchange), etc., etc.