Raid5 och raidz/raidz lika farliga?

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Okt 2010

Raid5 och raidz/raidz lika farliga?

Jag har förstått att med stora TB-diskar så är raid5 farligt och ska ej användas. Jag tycker mig ha sett samma sak sägas om raidz (1 paritetsdisk), men snubblar i förståelsen. Är det verkligen farligt då man med zfs kan säkra datans integritet, och således inte borde hamna i den dubbla fällan med en disk som fallerar och ett ure när man "bygger om"?

Fractal Design R3 ~ Seasonic X650 ~ Sabertooth X58 ~ i7 950 (@stock speed) w/ Megahalems ~ 18GB DDR3 1600MHz ~ Radeon HD 7750 passivt ~ 3 x SSD, 4 x WD Caviar Green ~ Linux Mint 18.1

Trädvy Permalänk
Medlem
Registrerad
Feb 2017

@guermantes:
Raid5 och RaidZ1 klarar båda att tappa en hårddisk. Det som då händer är att du pluggar in en ny fräsch disk i din gamla slitna raid array å börjar återskapa den. Detta är extremt mycket jobb i jämförelse med vad din array gör i normala fallet och risken att ytterligare en disk då dör är exponentiellt större än normalt. Om du tappar ytterligare en disk under återskapande fasen så förlorar du all din data.

Det är därför Raid6 eller RaidZ2 blev rekommendationen.

I ZFS världen har man dock börjat gå mer å mer åt att helt slopa raid för vdevs och gå över mot att köra mirror diskar istället. Risken att förlora data går ner, tiden det tar att återskapa en array går ner och det blir enklare att utöka en zpool.

http://jrs-s.net/2015/02/06/zfs-you-should-use-mirror-vdevs-n...

Trädvy Permalänk
Medlem
Plats
Örebro
Registrerad
Maj 2013

Kör Raid6 men när du kommit upp i x antal diskar blir även det riskabelt.

CPU: Intel Core i7 6700K Mobo: EVGA Z170 FTW GPU: Nvidia GeForce GTX 1080Ti Ram: Corsair 32GB (4x8GB) DDR4 3000Mhz PSU: Corsair AX860i SSD: Samsung 950-series PRO 256GB M.2 SSD: Samsung 850-Series PRO 512GB Chassi: Fractal Design Define C Kylning: Corsair Hydro H110i GTX Skärm: ASUS 27" ROG SWIFT PG279Q G-Sync OS: Windows 10 Pro 64-Bit VR: HTC Vive

Steam

Trädvy Permalänk
Medlem
Plats
-
Registrerad
Jul 2002
Skrivet av Garmzon:

I ZFS världen har man dock börjat gå mer å mer åt att helt slopa raid för vdevs och gå över mot att köra mirror diskar istället. Risken att förlora data går ner, tiden det tar att återskapa en array går ner och det blir enklare att utöka en zpool.

http://jrs-s.net/2015/02/06/zfs-you-should-use-mirror-vdevs-n...

och kostnaden går upp iom att man behöver dubblera antalet diskar.

.:Wks: Cooler Master Silencio 650|Core i5 3570 3.4 GHz|Asus P8Z77-V|8 GB| GT 465|1xDell U2311H, 2xAlienware AW2210 2xEizo 19|OCZ Revo 3 Drive 120 + Raptor 150:.
.:Server: Har ett gäng :) :.
-Learn the system, Play the system, Break the system-

Trädvy Permalänk
Medlem
Plats
Borås
Registrerad
Okt 2002
Skrivet av Garmzon:

@guermantes:
Raid5 och RaidZ1 klarar båda att tappa en hårddisk. Det som då händer är att du pluggar in en ny fräsch disk i din gamla slitna raid array å börjar återskapa den. Detta är extremt mycket jobb i jämförelse med vad din array gör i normala fallet och risken att ytterligare en disk då dör är exponentiellt större än normalt. Om du tappar ytterligare en disk under återskapande fasen så förlorar du all din data.

Det är därför Raid6 eller RaidZ2 blev rekommendationen.

I ZFS världen har man dock börjat gå mer å mer åt att helt slopa raid för vdevs och gå över mot att köra mirror diskar istället. Risken att förlora data går ner, tiden det tar att återskapa en array går ner och det blir enklare att utöka en zpool.

http://jrs-s.net/2015/02/06/zfs-you-should-use-mirror-vdevs-n...

Samtidigt kan man ha otur att båda diskarna i ett mirrorpar pajar vilket inte hade gjort något om man hade kört raidz2. I och för sig kan man ha 3 diskar i varje mirror...

Men istället för att fundera alltför mycket på det här så ser man till att ha bra fungerande backuper så att man kan återställa sina filer när det pajar. Det är väl hur pass mycket man tycker det är värt att slippa tiden det tar att återställa från backup som bestämmer vilken raidnivå man ska ha.

Trädvy Permalänk
Medlem
Plats
Malmö
Registrerad
Maj 2014
Skrivet av Garmzon:

@guermantes:
Raid5 och RaidZ1 klarar båda att tappa en hårddisk. Det som då händer är att du pluggar in en ny fräsch disk i din gamla slitna raid array å börjar återskapa den. Detta är extremt mycket jobb i jämförelse med vad din array gör i normala fallet och risken att ytterligare en disk då dör är exponentiellt större än normalt. Om du tappar ytterligare en disk under återskapande fasen så förlorar du all din data.

Det är därför Raid6 eller RaidZ2 blev rekommendationen.

I ZFS världen har man dock börjat gå mer å mer åt att helt slopa raid för vdevs och gå över mot att köra mirror diskar istället. Risken att förlora data går ner, tiden det tar att återskapa en array går ner och det blir enklare att utöka en zpool.

http://jrs-s.net/2015/02/06/zfs-you-should-use-mirror-vdevs-n...

Tror jag läst om detta också. RaidZ3 eller Mirrors är vad som anses "bra nog" idag.

Notera dock:

Skrivet av guermantes:

Är det verkligen farligt då man med zfs kan säkra datans integritet, och således inte borde hamna i den dubbla fällan med en disk som fallerar och ett ure när man "bygger om"?

RAID är inte backup, och du kan ge dig tusan på att din mirrorade RaidZ3 med 9+9 diskar dör av ett åsknedslag, eller brand, virus, kortslutning eller liknande.

Så... jag hade undvikt RAID 5, då det är med dagens stora diskar, som att sitta utan skydd. RAID 1 eller 10, alt RaidZ2 hjälper dig att hålla driften uppe, vilket är vad RAID är till för... öka drifttiden. Men om du saknar backup så ta hellre färre diskar med RAID5 och riktig "offline/offsite" backup, då det är betydligt bättre lösning (om pengarna är lite tajta dvs).

Trädvy Permalänk
Medlem
Registrerad
Feb 2017

@ronnylov:
allt är en ekonomisk kalkyl

kostnad för downtime mot kostnaden av backup
kostnaden för backup mot kostnaden av att återskapa förlorad data
kostanden för disk mot kostnaden för downtime etc

ZFS är ingen mirakelmaskin som gör att du slipper backup, men du slipper backup av tråkiga anledningar och du slipper förlora data

Själv har jag flera tiers av data, allt från sådant som enkelt kan återskapas eller är flyktigt till sådant som jag definitivt vill ha kvar om 40 år

och kostnaden per byte jag är villig att spendera skalar med det

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Okt 2010

Offline backup kommer jag definitivt att ha oavsett var jag hamnar i valet av NAS filsystem/lagringssetup.

Det jag försöker bedöma är hur jag ska konfigurera för att få en så felfri master som möjligt att göra backup på.

Det jag är skraj för är att jag börjar göra backup på korrupta filer utan att märka det, och att jag först märker det om fem år efter ett haveri då jag ska återställa.

Det är därför jag frestas så mycket av zfs anti-bit rot error correction. Men det här är nytt territorium för mig så jag kanske har mina prioriteringar fel.

Skickades från m.sweclockers.com

Fractal Design R3 ~ Seasonic X650 ~ Sabertooth X58 ~ i7 950 (@stock speed) w/ Megahalems ~ 18GB DDR3 1600MHz ~ Radeon HD 7750 passivt ~ 3 x SSD, 4 x WD Caviar Green ~ Linux Mint 18.1

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Okt 2010
Skrivet av Garmzon:

I ZFS världen har man dock börjat gå mer å mer åt att helt slopa raid för vdevs och gå över mot att köra mirror diskar istället. Risken att förlora data går ner, tiden det tar att återskapa en array går ner och det blir enklare att utöka en zpool.

http://jrs-s.net/2015/02/06/zfs-you-should-use-mirror-vdevs-n...

Mycket intressant läsning! Föranleder två frågor från novisen :

1) säg att man har 4 lika stora diskar och skapar två mirrored vdevs. Vad är poängen med att "samla dem" i en pool (som ju kommer fallera totalt om båda diskarna i ena vdev:en pajjar), jämfört med att låta dem endast existera som två vdevs? Det känns som en onödig risk att ta bara för att få ett lagringsutrymme på 1+1, istället för två lagringsutrymmen på 1 vardera.

2) för att zfs self-healing/antibitrot ska fungera (sker väl på vdev nivå, antar jag) behövs ju dubbelt så mycket raw disk space som storage space. Och för mirroring gäller väl samma. Men använder zfs samma fysiska disk för båda ändamålen, eller måste jag in med en tredje disk? Jag gissar att det räcker med två, men lyckas inte förklara det för mig själv utifrån min nuvarande kunskap om zfs.

Skickades från m.sweclockers.com

Fractal Design R3 ~ Seasonic X650 ~ Sabertooth X58 ~ i7 950 (@stock speed) w/ Megahalems ~ 18GB DDR3 1600MHz ~ Radeon HD 7750 passivt ~ 3 x SSD, 4 x WD Caviar Green ~ Linux Mint 18.1

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Okt 2010

https://forums.freenas.org/index.php?threads/mirrored-vdevs-v...

Oops... En av guruerna på freenas forumet menar att artikelns rekommendation inte är så bra när allt kommer omkring. Inlägg 2.
/ Tomas di leva börjar sjunga /

Skickades från m.sweclockers.com

Fractal Design R3 ~ Seasonic X650 ~ Sabertooth X58 ~ i7 950 (@stock speed) w/ Megahalems ~ 18GB DDR3 1600MHz ~ Radeon HD 7750 passivt ~ 3 x SSD, 4 x WD Caviar Green ~ Linux Mint 18.1

Trädvy Permalänk
Medlem
Plats
Borås
Registrerad
Okt 2002
Skrivet av guermantes:

Mycket intressant läsning! Föranleder två frågor från novisen :

1) säg att man har 4 lika stora diskar och skapar två mirrored vdevs. Vad är poängen med att "samla dem" i en pool (som ju kommer fallera totalt om båda diskarna i ena vdev:en pajjar), jämfört med att låta dem endast existera som två vdevs? Det känns som en onödig risk att ta bara för att få ett lagringsutrymme på 1+1, istället för två lagringsutrymmen på 1 vardera.

2) för att zfs self-healing/antibitrot ska fungera (sker väl på vdev nivå, antar jag) behövs ju dubbelt så mycket raw disk space som storage space. Och för mirroring gäller väl samma. Men använder zfs samma fysiska disk för båda ändamålen, eller måste jag in med en tredje disk? Jag gissar att det räcker med två, men lyckas inte förklara det för mig själv utifrån min nuvarande kunskap om zfs.

Skickades från m.sweclockers.com

1) Man skapar en pool för att få ett större samlat utrymme istället för många mindre lagringsutrymmen. Det ger mer flexibilitet. Man kan skapa flera pooler också om man vill.

2) Det går att återskapa data även med mindre redundans. Jämför med PAR2-filer som brukar (eller brukade, var längesedan jag kollade) användas på binära nyhetsgrupper. Där delas en fil upp i många små filer och så läggs några PAR2-filer till som redundans. Då kan man sakna någon av delarna om man har en PAR2-fil med checksummor. Med checksummorna kan man räkna baklänges för att återställa data. Men det funkar ju bara så länge det finns tillräckligt många checksummor för att kunna återskapa det som saknas. På samma sätt funkar raidz1 och raidz2.

Med 4 diskar i raidz1 så är 25% redundant och man kan tappa vilken som helst av de 4 diskarna eftersom det är checksummor som lagras på allihopa. ZFS använder checksummorna för att räkna ut filens innehåll i filsystemet och att verifiera att innehållet är rätt och även för att kunna reparera filer med hjälp av redundans. Raidz2 med 4 diskar har 50 % redundans och det är lika mycket redundans som två stycken mirrors med 4 diskar. Skillnaden med raidz2 är att vilka som helst 2 diskar kan gå sönder utan risk medan i fallet med mirrors så pajar det ju om båda diskarna i samma par går sönder.

En anledning att köra mirrors är mer för att få bättre prestanda. Man för bättre IOPS och alltså snabbare åtkomst av flera filer samtidigt. Poolen blir rappare helt enkelt. En annan anledning är att det är enklare att utöka poolen med fler diskar om man lägger till två åt gången.

En bra grej med ZFS även om man kör det på singeldisk utan redundans så kan ZFS tala om att filerna är opåverkade eller om de har skadats på grund av diskfel. Ett litet diskfel sabbar bara den fil som felet uppstod i och ZFS talar då om vilken fil som kan vara skadad och säger att man bör återskapa den från backup. Utan redundansen kan filen alltså inte repareras automatiskt men felet kan identifieras. En grej man kan göra för att få redundans även med en singeldisk är att ange parametern copies=2. Då blir det 2 kopior av varje fil på samma disk och fel kan repareras men med halverat diskutrymme som nackdel. Kan ju vara bra på en laptop.

Själv har jag en pool med två stycken raidz2 vdevs om 6 diskar vardera. Hade tidigare en pool med 11 diskar i raidz3 men tycker nuvarande setup presterar bättre och det går snabbare att ersätta trasiga diskar. Lite som ett mellanting mellan många mirrors och en enda stor raid. I fallet raidz3 kunde vilka som helst 3 stycken diskar paja utan problem men nu kan teoretiskt 3 diskar paja i samma vdev och poolen havererar i nuvarande setup. Samtidigt är risken att 3 diskar av 6 havererar inte lika stor som 3 diskar av 11. Det blir en kompromiss hur man än gör.

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Okt 2010
Skrivet av ronnylov:

2) Det går att återskapa data även med mindre redundans.....

Jag kanske uttryckte mig fel. Min undran var mer huruvida mirrorn också används för self-healing eller om jag behöver avsätta ytterligare utrymme för det. Vad jag förstår så funkar ZFS self-healing automatiskt om man konfigurerar nån variant av RAID, men av artikeln på jrs-s.net får jag intryck av att mirror vdevs är nåt annat än RAID (att mirrorn inte är samma sak som RAID-redundansen, dock har jag svårt att sätta ord på vad den då skulle vara).

Skrivet av ronnylov:

Skillnaden med raidz2 är att vilka som helst 2 diskar kan gå sönder utan risk medan i fallet med mirrors så pajar det ju om båda diskarna i samma par går sönder...... En anledning att köra mirrors är mer för att få bättre prestanda.

Från ett dataintegritetsperspektiv är alltså RAIDZ2 bättre än mirror vdevs? (För mig är dataintegritet viktigare än performance (fast det är ett plus att det är lättare att utöka med nya diskar med mirrors))

Skrivet av ronnylov:

...och det går snabbare att ersätta trasiga diskar.

Lite ovetenskapligt får jag intryck av att diskar går sönder och måste ersättas mycket oftare när man kör en filserver i en NAS än när man bara har några lagringsdiskar i sin desktop. Jag tycker det pratas mycket mer om att folk håller på och ersätter diskar i NAS-scenarier, än att de ersätter lagringsdiskar i sina desktops. Fast jag är kanske ute och snurrar? NAS-nissar kanske har bättre koll på SMART-värden och tar det säkra före det osäkra och byter ut, medan desktoplagrare kör på som vanligt tills det kraschar och många av dem slipper krasch för att de har tur eller märker aldrig att viss lagrad data har blivit korrupt?

Fractal Design R3 ~ Seasonic X650 ~ Sabertooth X58 ~ i7 950 (@stock speed) w/ Megahalems ~ 18GB DDR3 1600MHz ~ Radeon HD 7750 passivt ~ 3 x SSD, 4 x WD Caviar Green ~ Linux Mint 18.1

Trädvy Permalänk
Medlem
Plats
Borås
Registrerad
Okt 2002
Skrivet av guermantes:

Jag kanske uttryckte mig fel. Min undran var mer huruvida mirrorn också används för self-healing eller om jag behöver avsätta ytterligare utrymme för det. Vad jag förstår så funkar ZFS self-healing automatiskt om man konfigurerar nån variant av RAID, men av artikeln på jrs-s.net får jag intryck av att mirror vdevs är nåt annat än RAID (att mirrorn inte är samma sak som RAID-redundansen, dock har jag svårt att sätta ord på vad den då skulle vara).

Från ett dataintegritetsperspektiv är alltså RAIDZ2 bättre än mirror vdevs? (För mig är dataintegritet viktigare än performance (fast det är ett plus att det är lättare att utöka med nya diskar med mirrors))

Lite ovetenskapligt får jag intryck av att diskar går sönder och måste ersättas mycket oftare när man kör en filserver i en NAS än när man bara har några lagringsdiskar i sin desktop. Jag tycker det pratas mycket mer om att folk håller på och ersätter diskar i NAS-scenarier, än att de ersätter lagringsdiskar i sina desktops. Fast jag är kanske ute och snurrar? NAS-nissar kanske har bättre koll på SMART-värden och tar det säkra före det osäkra och byter ut, medan desktoplagrare kör på som vanligt tills det kraschar och många av dem slipper krasch för att de har tur eller märker aldrig att viss lagrad data har blivit korrupt?

Mirror funkar med self healing, behövs inget mer. En mirror är som två singeldiskar som speglar varandra automatiskt. Är en fil trasig på ena disken så går den att läsa från den andra. Det går lätt att göra om en singeldisk till mirror, den bara kopierar sig till två diskar. Man kan också lägga till en tredje disk och få en trippelmirror. Har man en singeldisk man vill klona kan man alltså göra en mirror och sedan koppla bort originaldisken när ZFS resilver är färdigt.

Raidz2 är bättre än 2-diskars mirrors ur dataintegritetsperspektiv om man har 4 diskar. Med 4 diskar kan man som sagt ha otur att två i samma mirror går sönder. Men med fler diskar äm 4 är det inte lika självklart. Säg att man har 3 stycken mirrors så kan det klara upp till 3 diskars haveri om man har tur men också haverera med två diskars fel om man har otur. Men man kan ha 3 diskar i varje mirror också förstås och man kan köra raidz3 med 6 diskar.

Jag tycker en lagom kompromiss är att köra 6 stycken diskar i raidz2. Med 2 diskar hare jag kört mirror. Med 3 diskar så hade jag nog kunnat tänka mig raidz1. 4 diskar så hade jag nog valt två mirrors eller raidz2. Kom på en till fördel med mirrors, diskarna behöver bara vara lika stora i varje par. Så om man börjar med två stycken 4TB skulle man kunna lägga till två stycken 8 TB senare. Med raidz2 behöver alla vara lika stora.

En fiserver eller NAS har ofta fler diskar än en desktopdator så sannolikheten att någon disk går sönder av alla de man har blir större när man har många. Å andra sidan har jag inte förlorat några data på grund av diskar som gått sönder och har alltså inte behövt återställa filer från backup på grund av den anledningen när jag kört ZFS. ZFS har också varit till hjälp att hitta krånglande diskar eller krånglande hårdvara. De första diskarna jag hade gav bitfel ibland som ZFS detekterade och reparerade. Kom på att diskarna inte gillade värme och de översta i hårddiskburen var varmare och det var dessa som krånglade mest. När jag bättrade på kylningen försvann dessa fel. I ett annat fall så fick jag fel på en av diskarna ibland och då visade det sig att jag hade en dålig SATA-kabel. Många kanske byter sina diskar så fort de ser minsta fel men jag har försökt hålla liv i dem så länge jag kunnat.

Trädvy Permalänk
Medlem
Plats
Malmö
Registrerad
Maj 2014
Skrivet av ronnylov:

Jag tycker en lagom kompromiss är att köra 6 stycken diskar i raidz2. Med 2 diskar hare jag kört mirror. Med 3 diskar så hade jag nog kunnat tänka mig raidz1. 4 diskar så hade jag nog valt två mirrors eller raidz2.

Rätta mig om jag har fel men RAID-Z2 har väl en fördel till som inte mirror har... ECC redundans även vid förlorad disk.

Mao.. säg att en disk rasar i vardera lösning. Du har då i mirror bara en enda kopia till, och om du får bit-fel (sektor fel tex), som ZFS kan upptäcka, kan den då inte göra mer än att säga att filen är korrupt, om den inte kan lyckas räkna rätt detta. (Då antagande att felet sker på den andra disken som är spegel av din rasade disk så klart).

Med RAID-Z2 så har den ju en bit uppsättning till, så även om en disk till läser bitfel så kan den bara återskapa detta med den sista checksumman från paritetsdisken som är kvar. Mao, du bör ha en liten nivå med självläkning kvar även på denna nivån.

Mao.. alla fel är inte total havri av diskar... små sektor fel, tysta bit-fel eller annat är också stort hot och anledningen varför många väljer just ZFS eller liknande med skrubbning.

Håller dock med dig i övrigt.

Trädvy Permalänk
Medlem
Plats
Borås
Registrerad
Okt 2002
Skrivet av Paddanx:

Rätta mig om jag har fel men RAID-Z2 har väl en fördel till som inte mirror har... ECC redundans även vid förlorad disk.

Mao.. säg att en disk rasar i vardera lösning. Du har då i mirror bara en enda kopia till, och om du får bit-fel (sektor fel tex), som ZFS kan upptäcka, kan den då inte göra mer än att säga att filen är korrupt, om den inte kan lyckas räkna rätt detta. (Då antagande att felet sker på den andra disken som är spegel av din rasade disk så klart).

Med RAID-Z2 så har den ju en bit uppsättning till, så även om en disk till läser bitfel så kan den bara återskapa detta med den sista checksumman från paritetsdisken som är kvar. Mao, du bör ha en liten nivå med självläkning kvar även på denna nivån.

Mao.. alla fel är inte total havri av diskar... små sektor fel, tysta bit-fel eller annat är också stort hot och anledningen varför många väljer just ZFS eller liknande med skrubbning.

Håller dock med dig i övrigt.

Ja med raidz2 så finns det 2 diskars redundans så du har 2 diskar att rätta bitfel ifrån. Å andra sidan är sannolikheten kanske inte jättestor att bitfel inträffar på samma fil i två diskar samtidigt. Men visst när en disk rasat har du inte kvar reparatinsförmågan i en mirror det stämmer (såvida det inte vsr en mirror med 3 diskar).

Behöver man prestanda för tex flera virtuella maskiner så kan mirrors vara ett bättre val. Man kan kompletteta med SSD cache i ZFS-poolen också (oavsett mirrors eller raidz2 i botten). Körde med detta ett tag men det gav inte så mycket i mitt fall då jag mest hade stora mediafiler. Använde min SSD dedikerat till den virtuella maskinen istället och dedikerade ZFS till lagring.

Skickades från m.sweclockers.com

Trädvy Permalänk
Medlem
Plats
Borås
Registrerad
Okt 2002

Hittade en relevant artikel i ämnet:
http://louwrentius.com/the-hidden-cost-of-using-zfs-for-your-...

Jag funderar på att köra detta i min kommande backupserver:
https://www.linuxserver.io/2016/02/02/the-perfect-media-serve...
snapraid + MergerFS

Detta verkar ha vissa fördelar i en hemma-NAS. Tänker en lagringsdator av denna typen kan spinna ner diskarna som inte används och man kan öka utrymmet med en disk i taget. ZFS är smidigt men inte alltid bästa valet.

Trädvy Permalänk
Medlem
Plats
Sthlm
Registrerad
Maj 2008
Skrivet av guermantes:

Mycket intressant läsning! Föranleder två frågor från novisen :

1) säg att man har 4 lika stora diskar och skapar två mirrored vdevs. Vad är poängen med att "samla dem" i en pool (som ju kommer fallera totalt om båda diskarna i ena vdev:en pajjar), jämfört med att låta dem endast existera som två vdevs? Det känns som en onödig risk att ta bara för att få ett lagringsutrymme på 1+1, istället för två lagringsutrymmen på 1 vardera.
Skickades från m.sweclockers.com

För varje vdev du har i en zpool så ökar IOPS med 100% (eller egentligen med IOPSen av den adderade vdeven då).

En server här, några servrar där.

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Okt 2010
Skrivet av ronnylov:

Jo, jag har sett louwrentius artikel. Onekligen bökigt att utöka zfs.

Citat:

Jag funderar på att köra detta i min kommande backupserver:
https://www.linuxserver.io/2016/02/02/the-perfect-media-serve...
snapraid + MergerFS

Detta verkar ha vissa fördelar i en hemma-NAS. Tänker en lagringsdator av denna typen kan spinna ner diskarna som inte används och man kan öka utrymmet med en disk i taget. ZFS är smidigt men inte alltid bästa valet.

Attans! Det där ser onekligen intressent ut. Tack för den.

Skickades från m.sweclockers.com

Fractal Design R3 ~ Seasonic X650 ~ Sabertooth X58 ~ i7 950 (@stock speed) w/ Megahalems ~ 18GB DDR3 1600MHz ~ Radeon HD 7750 passivt ~ 3 x SSD, 4 x WD Caviar Green ~ Linux Mint 18.1

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Okt 2010

Men... vågar man lita på små projekt som mergerfs jämfört med stora community projekt som zfs?

Skickades från m.sweclockers.com

Fractal Design R3 ~ Seasonic X650 ~ Sabertooth X58 ~ i7 950 (@stock speed) w/ Megahalems ~ 18GB DDR3 1600MHz ~ Radeon HD 7750 passivt ~ 3 x SSD, 4 x WD Caviar Green ~ Linux Mint 18.1

Trädvy Permalänk
Medlem
Registrerad
Feb 2017
Skrivet av guermantes:

Men... vågar man lita på små projekt som mergerfs jämfört med stora community projekt som zfs?

Skickades från m.sweclockers.com

Nej

Trädvy Permalänk
Medlem
Registrerad
Aug 2015
Skrivet av guermantes:

Jag har förstått att med stora TB-diskar så är raid5 farligt och ska ej användas. Jag tycker mig ha sett samma sak sägas om raidz (1 paritetsdisk), men snubblar i förståelsen. Är det verkligen farligt då man med zfs kan säkra datans integritet, och således inte borde hamna i den dubbla fällan med en disk som fallerar och ett ure när man "bygger om"?

När jag började med raid för hemmabruk 2003 nångång så var det mdadm som gällde. Undvek hårdvaruraid främst för att undvika problem ifall raid-kontrollern skulle paja.

Blev raid6 på backupservern (8 diskar) och raid5 på driftservern (upp till 4 diskar).

För att kolla "bit-rot" så kör jag md5sum på alla filer och kollar sen att det stämmer med vissa intervall.

Detta visade sig vara nödvändigt då vissa moderkort inte klarade av att man accessade flera snabbare diskar samtidigt. (Äldre kort designade när udma33 var vad som fanns så sket sig med snabbare diskar, har inte haft det problemet på modernare kort).

Min erfarenhet är att diskar börjar uppvisa dåliga sektorer innan de fallerar helt, så om lång smart-test som scannar hela ytan går igenom utan problem så är det ok. Om inte så är det dags att byta den disken. Då gör man först en inkrementell backup för att få med ändringarna sen senaste backup. (Minst risk att man pajar nån mer disk på detta sätt.) Sen kan man köra en total-backup om man vill. Sen byter man disken och synkar om arrayen. Skulle man få då få katastrof-fel så har man en färsk backup att rulla tillbaka.

Samma sak om man ska öka ut den, kolla först att alla diskar är OK med smart, gör ny backup, bygg ut.

Har funkat för mig och jag har inte förlorat nåt data trots att några diskar dött.