mboost-dp1

grim OpenZFS bug


Gå til bund
Gravatar #2 - larsp
28. nov. 2023 10:11
at the same time when ZFS is still writing the data, the modified part of file is being read from. The same time means "hit a very specific time", measured in microseconds (that's millionth of a second), wide window. (...) if it is being read at this very specific moment, the reader will see zeros where the data being written is actually something else

Lol. Det er jo en klassisk race condition, som journalisten får til at lyde som noget helt specielt og meget usandsynligt. "millionth of a second" ! wow.

En race condition i et filsystem er fuldstændigt uacceptabelt og utrolig pinligt.

Men jeg må melde hus forbi. Jeg har aldrig set behovet for at rode med eksotiske filsystemer og er forundret over alle dem der eksperimenterer med den slags og brænder fingrene igen og igen. Et filsystem skal IMO være så kedeligt som muligt og bare holde filerne uden at korrumpere. Det klarer de sædvanlige ext2,3,4 og NTFS systemer udmærket. Alt hvad der backup og versionsstyring er bedst at bygge *ovenpå* filsystemet i stedet for at bruge fancy features i et eksperimentelt filsystem.
Gravatar #3 - larsp
28. nov. 2023 10:27
Jeg er heller ikke fan af RAIDede drev. Det at have to eller flere consumer-grade drev kørende lige op af hinanden, så de overfører vibrationer og varme, er en opskrift på ødelægge drev før tid. Og når det ene drev så står af er det andet drev med garanti allerede mørt og der er al for stor risiko for at det også giver op i rekonstruktionsfasen.

RAID for hastighed? Irrelevant i disse dage med SSD. RAID for større kapacitet? Tåbeligt, det er alt for risikabelt (og klodset) at have partitioner så store at de ikke kan lægge på ét drev. RAID for datasikkerhed? Minimal fordel hvis overhovedet, som beskrevet gør RAID bare at drevene går i stykker før tid og er nede i dagevis mens de rekonstruerer, hvis det overhovedet lykkes. RAID for backup? Haha.
Gravatar #4 - arne_v
28. nov. 2023 14:57
larsp (2) skrev:

Men jeg må melde hus forbi. Jeg har aldrig set behovet for at rode med eksotiske filsystemer og er forundret over alle dem der eksperimenterer med den slags og brænder fingrene igen og igen. Et filsystem skal IMO være så kedeligt som muligt og bare holde filerne uden at korrumpere.


Der er også nogen som går op i filsystemets performance.

larsp (2) skrev:

Det klarer de sædvanlige ext2,3,4 og NTFS systemer udmærket. Alt hvad der backup og versionsstyring er bedst at bygge *ovenpå* filsystemet i stedet for at bruge fancy features i et eksperimentelt filsystem.


I en IT operations venlig verden ligger backup over filsystemet. Man lukker systemerne ned, laver en backup og starter systemerne op igen. I den virkelige verden står brugerne og forretningen og insisterer på 24 x 7 drift. Det er ikke trivielt at lave en konsistent backup af et kørende system uden en tæt integration mellem applikation, filsystem/fysisk-storage og backup program.

Typisk:
* backup program startes
* applikation pauser nye opdateinger
* applikation færdiggør udestående opdateringer og kommer i konsistent tilstand on disk
* applikation melder ud til filsystem/fysisk-storage at alle i brug disk blokke er frosset
* backup program laver backuppen
* applikationen processer nye opdateringer men skriver kun til nye disk blokke
* backup program melder ud til filsystem/fysisk-storage at disk blokke som ikke længere er i brug kan genbruges

Gravatar #5 - arne_v
28. nov. 2023 15:51
#3

Jeg kan ikke helt følge dig.

De fleste servere og en del high-end PC har altid haft flere diske. Med korrekt montering og passende køling bør vibration og varme det ikke være et problem med consumer-grade HDD. Og slet ikke noget problem med SSD.

Et system kan fint køre under rekonstruktion. Forringet performance men det kører. Og det går rimeligt hurtigt med SSD (vel en 30-60 minutter per TB med SSD og 5-10 timer per TB med HDD).
Gravatar #6 - arne_v
28. nov. 2023 16:59
#5

Min personlige erfaring (hvilket man jo altid skal være meget forsigt med at udlede for meget af) er:
* sidste i 80'erne: server med 480 og 620 MB diske, ingen RAID, 480 MB diskene var noget møg, der gik en om måneden, diskene blev skiftet og restoret fra natlig backup, tab af data og tab af tid for de brugere som var på den disk
* først i 00'erne: server med 4 og 9 GB diske, plug and play diske, RAID-1 og RAID-5, der gik en disk en gang imellem, gammel disk ud og i skraldespanden, ny disk fra hylden og ind, 2 minutter, ingen driftsforstyrrelse
* 2011: ny hjemme PC, saml selv, to 2 TB diske i RAID-1 med en spare på hylden, efter få måneder gik den ene disk, erstat med spare (og sende defekt ind og få ny under garanti), ingen data tab, en halv times arbejde da ikke plug and play så nødt til at åbne kabinettet, og så kørte diskene uden problemer i 11 år (fungerer stadig, men bruger ikke PC længere, og spare er stadig i en kasse et eller andet sted)

Så jeg kan godt lide RAID-1.

(min sidst i 00'erne hjemme PC havde to 10K RPM diske i RAID-0 for performance, men det var jo lidt risikabelt)

Gravatar #7 - larsp
29. nov. 2023 12:11
#5 #6
480 MB diskene var noget møg, der gik en om måneden

Det har jeg godt nok aldrig været ude for. Jeg har været velsignet med kun at have oplevet to eller tre drev fejle i hele min computer-forbrugs-historik, inklusive laptops. Dertil én SSD der gik i skoven. Og uden at tælle diverse retro-computer arkæologi -oplevelser.

Men det slår mig, at du netop har oplevet temmelig mange drev der fejler med dine RAID setups. Jeg tror at belastningsprofilen ved RAID, hvor folk ofte har en lille NAS-kasse med en bunke crappy drev lige op af hinanden der varmer og ryster hinanden i stykker, bare gør at drevene bare går i stykker hyppigere. Dertil at der er flere drev i spil øger også antallet af "events" pr. tid.

Anekdotisk igen ... kan man sammenligne med det koncept jeg har kørt med til min personlige filserver i over 15 år. En always-on PC (mini-ITX) med een always-spinning disk til bulk storage, og een ekstern disk der kun startes op i forbindelse med det daglige backup job. Med denne server har ikke en eneste gang oplevet drev der fejlede mekanisk.

Min teori er, at et drev der ikke oplever temperatursvingninger (always spinning), ikke er ret hårdt belastet og er alene i kabinettet, får de absolut bedste betingelser for at leve længe.

Det er som om man kan gå i to grøfter. Enten mit koncept (der vel og mærket ikke skalerer) som holder drevene i live meget længe, eller at gå all-in med RAID og acceptere at der ryger et drev ind imellem.

Det med RAID genetablering, der får de resterende drev til at dø og tager dagevis, medgiver jeg nok er skudt lidt ved siden af og er da også baseret på skrækeksempler man kan læse om online. Inklusiv uheldige oplevelser med shingled writing (SMR) drev.
Gravatar #8 - arne_v
29. nov. 2023 13:32
larsp (7) skrev:
#5 #6
480 MB diskene var noget møg, der gik en om måneden

Det har jeg godt nok aldrig været ude for.


Det var en anden tid.

:-)

Jeg slog den op.

Jeg huskede forkert - det var ikke 480 MB men 456 MB.

Dimension: 10.5 x 16 x 36 tommer.

Vægt: 148 pund.

Strømforbrug idle: 644 watt.

Ikke oplagt som laptop disk.

:-)

Den høje fejlrate skyldes en fabrikationsfejl.

Men selv de gode diske fra den tid havde en meget højere fejlrate (lavere MTBF) end idag.

Backup blev planlagt og software designet efter at diske kunne fejle.

Med Sybase (MS SQLServer er en Sybase klon) var det almindeligt at lade databasen lave mirror - man konfigurerede den til at skrive database indholdet i 2 kopier (på 2 forskellige diske). Så kunne man overleve at en disk gik uden at skulle have HW eller OS RAID.


Gravatar #9 - arne_v
29. nov. 2023 13:45
#7

Personligt har jeg ikke været så hårdt ramt. 25 år arbejds laptop - en disk som Windows sagde burde skiftes og som blev skiftet uden data tab inden den stod af. 25 års hjemme PC (single disk, RAID-0, RAID-1) en disk som stod af i RAID-1 setup relativt kort tid efter ibrugtagning.

Men servere er en anden sag. Eller var ihvertfald. Mange diske (dusinvise - hundredevise) i 365 x 24 drift og heftig brug som f.eks. database brug. I gamle dage betød det at der gik en disk i ny og næ. Idag er det sjældnere, men det sker stadig.

Lidt Googling antyder at MTBF er steget fra 10000 timer til 1 million timer på diske fra 1980 til 2020. Der er 8760 timer i et år. Selv idag skal man med 100 diske regne med at der går ca. 1 om året.
Gravatar #10 - arne_v
29. nov. 2023 14:12
OpenZFS har iøvrigt stadig problemer:

https://www.phoronix.com/news/OpenZFS-Data-Corrupt...
Gravatar #11 - larsp
29. nov. 2023 14:33
arne_v (8) skrev:
Men selv de gode diske fra den tid havde en meget højere fejlrate (lavere MTBF) end idag.

Min fornemmelse er, at det er gået lidt ned af bakke igen de seneste måske 5 år, hvad angår pålidelighed for spinning rust. Producenterne ved, at den eneste use case der er tilbage er ekstrem høj kapacitet, så produktlinjerne har generelt utrolig høj datadensitet på skiverne med shit som shingled recording for at nå dertil. Så, hvis man kun vil have f.eks. 4 TB får man måske en skive eller to i dag, hvor man før ville få 4 - 6 skiver med lidt mere afslappet densitet og uden så meget pjat. Jeg er ikke sikker på at disse moderne diske kan holde 10+ år uden issues, som diske for 10 år siden typisk kunne.

Da jeg skulle købe en ny disk til mit backupsystem var det faktisk svært at finde en der IKKE var shingled, i det prisbillige udvalg i min lokale hardware biks. Jeg kiggede mest på de prisbillige Western Digital's, for det mærke har altid gjort det godt for mig. Jeg endte med at måtte vælge en WD Purple 4 TB for at få en ikke-shingled disk egnet til mit formål - og Purple er udviklet til at gemme video i overvågningssystemer.
Gravatar #12 - arne_v
29. nov. 2023 15:00
#11

Jeg tror du har ret med hensyn til HDD markedet idag - det er blevet et en-parameter markede - kroner per GB er altafgørende. Og det kan godt presse kvaliteten.

Jeg har også brugt WD i mange år i mine saml selv PC. Men den sidste blev købt færdig samlet og det blev med en Toshiba HDD (udover de 3 SSD).

Jeg var ikke opmærksom på shingled problematikken (det er for lang tid siden jeg har gjordt i HW). Men jeg checkede lige - min Toshiba er en CMR ikke en SMR.
Gravatar #13 - arne_v
29. nov. 2023 15:12
#12

https://toshiba.semicon-storage.com/content/dam/to...

De koster 160 dollar for en 4 TB i løs vægt, hvilket er meget dyrt, men jeg gav meget mindre for den i en pakke løsning. 40 dollar eller deromkring.
Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login