Temporär lagring och filsystem

Permalänk
Medlem

Temporär lagring och filsystem

Har en HP Microserver gen8 som hemmaserver. Den kör just nu Ubuntu 20.04 på en SSD och har 2x 8TB diskar i RAID 1. Ligger dock lite på gränsen och har därför beställt 2x 14TB. Men har lite funderingar.

Innan man byter, hur kan man göra med lagringen av de nuvarande 8TB. Är det bäst att skapa den nya RAID:en och sedan stoppa in en av 8TB i fjärde slotten och synka över eller finns det andra sätt?

På servern finns även min lokala kopia av familjebildsbiblioteket. Just nu har jag ext4, men med de nya diskarna funderar jag på att byta till ZFS. Eller är det bättre med btrfs?

Permalänk
Medlem

Hej, några tankar:

Fundera på att köra ett mer renodlat server/nas-os, t.ex. TrueNAS
https://en.wikipedia.org/wiki/TrueNAS

Citat:

hur kan man göra med lagringen av de nuvarande 8TB. Är det bäst att skapa den nya RAID:en och sedan stoppa in en av 8TB i fjärde slotten och synka över eller finns det andra sätt?

Chassit får inte plats med alla hårddiskar på samma gång? Då låter det rätt rimligt att gå tillväga så att du "bryter upp" din Raid1 till icke-raid hårddisk, frigör utrymme så du kan sätta upp den nya Raid:en, och synka över data så fort som möjligt.

ZFS eller btrfs är båda bra val. Jag skulle säga att mjukvaran (OS:et m.m.) runtomkring är viktigare, t.ex. TrueNas där man ställer in regelbunden skanning av hårdvaran för att upptäcka datakorruption.

Permalänk
Medlem

Kan du köra zfs verkar det vara rätt mycket bättre än btrfs, även mirror är rätt flaky med btrfs under vissa omständigheter. Och inga RAID-lägen gör ett dyft för uptime med btrfs heller eftersom det vägrar mounta utan en speciell flagga om en disk är paj. Se gärna till att ha backup (alltid bra att ha) innan du gör något oavsett vad du kommer fram till. Hur många diskar har du plats för?

Visa signatur

RAID is not a backup

Permalänk
Medlem

Jag skulle inte döma det så - prova båda (linux har inga problem att köra flera flera olika filsystem samtidigt), stressa med olika skrivlaster och med användning ser vilken du trivs bäst med.

En RAID måste du ändå ha regelbunden backup på och speciellt med ZFS då det inte är mycket att laga eller försöka rädda data ur den dagen det havererar.

Själv kan jag omöjligen undvara BTRFS snapshotmöjligheter i backupsammanhang när man väl smakat och förstått hur bra de är och att det är helt oberoende volymer som skapas med snapshot som kan tas bort i vilken ordning som helst och var och en kan modifieras hur som helst i olika riktningar utan beroende eller påverkan av någon annan subvolym och har svårt för ZFS hierakieska motsvarighet med beroende mellan snapshot-generationer där man inte kan rensa i snapshoten i valfri ordning för att återskapa diskplats, modifiera olika versioner av snapshot fritt och kunna ha schemalagd utglesning av backuper beroende på hur gamla de är... hade open source ZFS någon gång fått tummen ur och implementerat 'reflink' som orginal solaris ZFS faktiskt har - så hade det hela varit lättare att svälja - men av någon anledning är opensource-kodarna för ZFS varit extremt reluktanta att implementera det trots att det tjatats om det i över 10 år... med 'reflink' så hade man kunna kopiera mellan dataset där bara ny metadata skapas medans nya metadatat fortfarande pekar på datadelen av filerna som finns i orginal dataset och istället för flera timmar kopiering där all data skall läsas och skrivas på ny ställe i lagringen så hade en ny dataset som kopia av instans i orginalets dataset kunna skapas på typ 30 sekunder till ett par minuter för typ 1 miljon filer på 1 TB sammanlagd storlek som man kan göra i BTRFS och det är bara nya metadatat som tar extra plats på disken i ZFS, inte dubbel kopia av allt (när man inte har sektordedupliceringen påslagen - och det av flera skäl)...

Ett råd är att inte använda ZFS på vdev baserade på flera externa USB-diskar samtidigt, dels av att en del modeller stänger av spindelmotorn efter en relativt kort tid inaktivitet och uppspinningstiden är farligt nära 8 sekunder och är responstider över detta sparkas disken direkt ut ur ZFS-RAID:en, och speciellt inte dagens versioner av externa USB-diskar då de mindre än 8-10 TB är SMR-diskar och de kan vara 'borta' mer än 20-30 sekunder utan respons när de 'nödstädar' sin PMR-del om disken inte får pauser i avseende skrivning/läsning så att de hinner städa ändå - och sådan läge när disken aldrig får paus är vid synkning/'resilver' av RAID under många timmar, ja hela dygn och beroende på skrivmönster som där man backar och skriver om redan nys skrivna sektorer under synkning/resilvering kan en sådan PMR-område i en SMR-disk fyllas upp väldigt kvickt (det är det mönster som gör att NTFS-filsystem tar ihjäl en SMR-disk tämligen fort när man kopierar över större mängder småfiler på en gång utan paustid).

När det gäller 'kritik' för olika filsystem - kolla när dessa skrevs då de som är flera år gamla har inte samma vikt som de som är mindre än 3 månader - då menar jag nya saker och inte upprepande av samma saker som skrevs 3 år innan då det trots allt utvecklas och putsas på båda filsystemen hela tiden och stora fel som har konsekvens i praktiken åtgärdas ganska snabbt - sedan finns det filosofiska saker på var som borde och inte borde - men det viktiga är om det har någon betydelse i faktiska utfall - jag har provat tex. BTRFS native RAID5/6 under typ 3 år med krånglande och utbytta diskar, bakgrunds deduplicering med bees hela tiden och den är inte sämre än tex. klassisk mdadm-RAID och vissa fall klarar sig bättre än mdadm-RAID vid tex. flera strömavbrott kort efter varandra och att resynkningen inte hinner blir klar mellan dess - eller kort sagt jag har förlorat data med mdadm-RAID men inte förlorat/fått korrupt data med BTRFS i native RAID5/6 under samma yttre omständighet med flera strömavbrott kort efter varandra.

Men det går givetvis att hitta ett syntetiskt felmönster som även kraschar BTRFS-RAID om man vill - men det är inget jag råkat ut för hittills.

Permalänk
Medlem
Skrivet av xxargs:

Jag skulle inte döma det så - prova båda (linux har inga problem att köra flera flera olika filsystem samtidigt), stressa med olika skrivlaster och med användning ser vilken du trivs bäst med.

En RAID måste du ändå ha regelbunden backup på och speciellt med ZFS då det inte är mycket att laga eller försöka rädda data ur den dagen det havererar.

Själv kan jag omöjligen undvara BTRFS snapshotmöjligheter i backupsammanhang när man väl smakat och förstått hur bra de är och att det är helt oberoende volymer som skapas med snapshot som kan tas bort i vilken ordning som helst och var och en kan modifieras hur som helst i olika riktningar utan beroende eller påverkan av någon annan subvolym och har svårt för ZFS hierakieska motsvarighet med beroende mellan snapshot-generationer där man inte kan rensa i snapshoten i valfri ordning för att återskapa diskplats, modifiera olika versioner av snapshot fritt och kunna ha schemalagd utglesning av backuper beroende på hur gamla de är... hade open source ZFS någon gång fått tummen ur och implementerat 'reflink' som orginal solaris ZFS faktiskt har - så hade det hela varit lättare att svälja - men av någon anledning är opensource-kodarna för ZFS varit extremt reluktanta att implementera det trots att det tjatats om det i över 10 år... med 'reflink' så hade man kunna kopiera mellan dataset där bara ny metadata skapas medans nya metadatat fortfarande pekar på datadelen av filerna som finns i orginal dataset och istället för flera timmar kopiering där all data skall läsas och skrivas på ny ställe i lagringen så hade en ny dataset som kopia av instans i orginalets dataset kunna skapas på typ 30 sekunder till ett par minuter för typ 1 miljon filer på 1 TB sammanlagd storlek som man kan göra i BTRFS och det är bara nya metadatat som tar extra plats på disken i ZFS, inte dubbel kopia av allt (när man inte har sektordedupliceringen påslagen - och det av flera skäl)...

Ett råd är att inte använda ZFS på vdev baserade på flera externa USB-diskar samtidigt, dels av att en del modeller stänger av spindelmotorn efter en relativt kort tid inaktivitet och uppspinningstiden är farligt nära 8 sekunder och är responstider över detta sparkas disken direkt ut ur ZFS-RAID:en, och speciellt inte dagens versioner av externa USB-diskar då de mindre än 8-10 TB är SMR-diskar och de kan vara 'borta' mer än 20-30 sekunder utan respons när de 'nödstädar' sin PMR-del om disken inte får pauser i avseende skrivning/läsning så att de hinner städa ändå - och sådan läge när disken aldrig får paus är vid synkning/'resilver' av RAID under många timmar, ja hela dygn och beroende på skrivmönster som där man backar och skriver om redan nys skrivna sektorer under synkning/resilvering kan en sådan PMR-område i en SMR-disk fyllas upp väldigt kvickt (det är det mönster som gör att NTFS-filsystem tar ihjäl en SMR-disk tämligen fort när man kopierar över större mängder småfiler på en gång utan paustid).

När det gäller 'kritik' för olika filsystem - kolla när dessa skrevs då de som är flera år gamla har inte samma vikt som de som är mindre än 3 månader - då menar jag nya saker och inte upprepande av samma saker som skrevs 3 år innan då det trots allt utvecklas och putsas på båda filsystemen hela tiden och stora fel som har konsekvens i praktiken åtgärdas ganska snabbt - sedan finns det filosofiska saker på var som borde och inte borde - men det viktiga är om det har någon betydelse i faktiska utfall - jag har provat tex. BTRFS native RAID5/6 under typ 3 år med krånglande och utbytta diskar, bakgrunds deduplicering med bees hela tiden och den är inte sämre än tex. klassisk mdadm-RAID och vissa fall klarar sig bättre än mdadm-RAID vid tex. flera strömavbrott kort efter varandra och att resynkningen inte hinner blir klar mellan dess - eller kort sagt jag har förlorat data med mdadm-RAID men inte förlorat/fått korrupt data med BTRFS i native RAID5/6 under samma yttre omständighet med flera strömavbrott kort efter varandra.

Men det går givetvis att hitta ett syntetiskt felmönster som även kraschar BTRFS-RAID om man vill - men det är inget jag råkat ut för hittills.

Fast med Btrfs vet man i många fall inte att saker gått sönder till skillnad från ZFS, send/receive lämnar trasiga snapshots som ser hela ut om man avbryter den, diskar som försvinner och dyker upp resulterar i data som inte är synkad vilket inte märks förän en disk går sönder och den andra inte har all data osv. Hänvisar till Jim Salters rätt så nya och genomgående test av diverse funktioner i Btrfs (en del snack om det i 2.5 admins, tror en del eller allt finns på Ars Technica). Väldigt många problem med Btrfs har hängt med i många år, så det är klart att om man struntar i allt äldre än några månader så ser det bra ut. Lyssnade nyligen på en jämförelse mellan Btrfs och klassisk RAID där Btrfs fortfarande har en del nackdelar.

Jag kör Btrfs på några av mina datorer men planerar att byta till ZFS framöver. Har man inte ZFS så är Btrfs förmåga att upptäcka skadad data väldigt trevlig, men det gör sig fortfarande bäst ovanpå RAID om man har flera diskar. Det går att använda (på flera diskar) om man är duktig på det men det är många luriga saker och fallgropar. ZFS är inte helt superlätt heller men det har inte samma benägenhet att dölja problem över tid. Om man ska prestandatesta så kan det vara värt att tweaka ZFS en del vilket kan göras per dataset i stor utsträckning.

Visa signatur

RAID is not a backup