Corrupte foto op ZFS

[Ceaus]

Ik heb mijn foto's op ZFS staan op een gemirrorde pool. Nu zit ik in mijn foto archief te kijken en kom deze tegen:

Helaas heb er daar een flink aantal van. De kleur van het vlak wisselt. Kan ook groen of blauw zijn. En de ernst van de corruptie varieert natuurlijk ook.

Ik kan me niet voorstellen dat deze foto's al gaar waren voordat ik op ZFS ben overgegaan (>10 jaar geleden). Ik draai 1x per maand een scrub.

Ik zou dus verwachten dat ZFS dit met een gemirrorde pool (2x4TB) had moeten fixen. Is dat een verkeerde aanname?

[Renault]

Symptoombestrijding: heb je geen intacte backup die je kunt controleren en van waaruit je de hele verzameling kunt overschrijven?

[DukeBox]

En als je een backup hebt, kan je van beiden de hash bekijken of de bestanden daadwerkelijk anders zijn?

[Vorkie]

Ceaus schreef op vrijdag 17 januari 2025 @ 19:00:
Ik heb mijn foto's op ZFS staan op een gemirrorde pool. Nu zit ik in mijn foto archief te kijken en kom deze tegen:
[Afbeelding]
Helaas heb er daar een flink aantal van. De kleur van het vlak wisselt. Kan ook groen of blauw zijn. En de ernst van de corruptie varieert natuurlijk ook.

Ik kan me niet voorstellen dat deze foto's al gaar waren voordat ik op ZFS ben overgegaan (>10 jaar geleden). Ik draai 1x per maand een scrub.

Ik zou dus verwachten dat ZFS dit met een gemirrorde pool (2x4TB) had moeten fixen. Is dat een verkeerde aanname?

Wel ECC geheugen?

[Ben(V)]

Als het allemaal soortgelijke manier corrupt zijn is het zeer onwaarschijnlijk dat het aan ZFS ligt, als dat al zou kunnen.
De corruptie zou dan random zijn.

Lijkt meer met ofwel een weergave probleem of je kijkt nu gewoon naar een thumbnail die bedoelt is voor een ander formaat.

[Ceaus]

Renault schreef op vrijdag 17 januari 2025 @ 20:09:
Symptoombestrijding: heb je geen intacte backup die je kunt controleren en van waaruit je de hele verzameling kunt overschrijven?

Nee helaas. Ik maak één keer per week een backup naar een externe USB disk en daar blijft het bij. Ik heb me erbij neergelegd dat het digitale leven van mijn archief eindig is.

[Ceaus]

Ben(V) schreef op vrijdag 17 januari 2025 @ 20:50:
Als het allemaal soortgelijke manier corrupt zijn is het zeer onwaarschijnlijk dat het aan ZFS ligt, als dat al zou kunnen.
De corruptie zou dan random zijn.

Lijkt meer met ofwel een weergave probleem of je kijkt nu gewoon naar een thumbnail die bedoelt is voor een ander formaat.

Goeie suggestie! Ik ga wat foto's kopiëren naar andere omgevingen om te zien hoe ze er daar uit zien. Het zijn oude Canon CR2 bestanden. Ik heb geen idee hoe de image decoders door het leven gaan op Linux, maar dit moment is zeker de moeite waard om daar met andere ogen naar te kijken.

[Ceaus]

Vorkie schreef op vrijdag 17 januari 2025 @ 20:36:
[...]


Wel ECC geheugen?

Bij ZFS is het gebruik van ECC een religieus onderwerp wat ik nadrukkelijk uit te weg ga.

[DukeBox]

Wij gebruiken btrfs als filesystem. Met de vele 100en terrabytes aan fotos die wij opslaan ben ik in al die jaren nog maar 1 btrfs melding tegen gekomen over een corrupt greaakt beeld (datarot).

Alle andere keren van corruptie was het dus niet het filesystem maar (client) manipulatie van het bestand. Simpelweg een bestand van share a naar share b verplaatsen via een client kan al zoiets veroorzaken. Dat is volledig transparant voor het filesystem, ecc geheugen etc...

[MAX3400]

Ceaus schreef op zaterdag 18 januari 2025 @ 10:20:
[...]

Bij ZFS is het gebruik van ECC een religieus onderwerp wat ik nadrukkelijk uit te weg ga.

ECC heeft weinig tot niets te maken met (uiteindelijk) het gebruikte filesystem dus verdiep je er toch eens in?

ECC memory is de basis waarmee elke handeling op de betreffende machine "vlekkeloos" via het RAM gecontroleerd en uitgevoerd kan worden (hele basic uitleg). Echter neemt dat nog steeds niet weg dat zodra er een bestand wijzigt tijdens create/modify/delete, bijna in alle gevallen door externe factoren, dat dus niet wordt opgevangen door ECC (want daar is het niet voor bedoeld).

Een en ander wordt vast duidelijker als je het OSI-model raadpleegt; er zijn tientallen uren te discussieren hierover

[Ceaus]

DukeBox schreef op zaterdag 18 januari 2025 @ 11:44:
Alle andere keren van corruptie was het dus niet het filesystem maar (client) manipulatie van het bestand. Simpelweg een bestand van share a naar share b verplaatsen via een client kan al zoiets veroorzaken. Dat is volledig transparant voor het filesystem, ecc geheugen etc...

Eens hoor, het kan op vele manieren verkeerd aflopen.

[dcm360]

De opties zijn eigenlijk wel grofweg dat de bestanden bij het wegschrijven al corrupt waren, dat ze tijdens het wegschrijven corrupt geraakt zijn, of dat er overige software aan de bestanden heeft gezeten. De kans dat ZFS zonder verdere signalen (scrubs met heel veel fouten) na het wegschrijven de data sloopt is minimaal. In het ideale geval zou je een snapshot hebben van vlak na het originele wegschrijven (die maak ik over het algemeen wel bij dergelijke datasets, in theorie gaat er nooit naar de bestanden geschreven worden en kost het dus geen ruimte), waarmee je zou kunnen vaststellen of/wanneer er toch naar de bestanden geschreven is.

[jan99999]

Foto's ook op andere computers eens openen, of andere photo viewer.
Als de fout zeer minimaal is, dan zou het mogelijk kunnen zijn, dat als je veel photo viewer gebruikt, dat er 1 het wel goed opent, dit is me gelukt met een zeer oude photo viewer, daarna via deze programma weer opgeslagen.

Als je een backup maakt , ook altijd een backup programma gebruiken,die ook de origineel en kopie vergelijkt, tijdens backup maken, en ja dit duurt zeer lang. Dus niet een kopie maken met de verkenner.
Freefilesync is een gratis programma, waar je een backup mee kunt maken maar ook sync(kopie) maken, maar met bit by bit controle. Ook 2 hd's die hetzelfde zijn kun je bit by bit controleren.

Ook om problemen te voorkomen, doe dit op je hardware te testen:
Maak van vele iso files, een par2, dan kun je meerdere van deze files, over netwerk sturen, en dan de par2 laten lopen, om te checken of netwerk goed werkt. Stuur dus heel veel GB tegenlijk om alles flink te belasten.
Via netwerk heb ik eens gezien dat 1 op de 10 files fout was, en er van de pc geen foutmelding kwam.
En je weet, je gebruikt bijna nooit je backup, dus een fout zul je niet merken.

Dit kun je natuurlijk ook doen op een externe schijf om te checken of deze goed werkt.
Een nieuwe hd doe ik bijv smart bekijken, schijf vol schrijven, par2 checken, en weer smart bekijken of schijf nog goed is. Natuurlijk ook ssd en usb stick zo testen/belasten of ze goed werken.

[ Voor 7% gewijzigd door jan99999 op 18-01-2025 23:53 ]

[Ceaus]

dcm360 schreef op zaterdag 18 januari 2025 @ 15:45:In het ideale geval zou je een snapshot hebben van vlak na het originele wegschrijven (die maak ik over het algemeen wel bij dergelijke datasets, in theorie gaat er nooit naar de bestanden geschreven worden en kost het dus geen ruimte), waarmee je zou kunnen vaststellen of/wanneer er toch naar de bestanden geschreven is.

Uitermate slimme en verstandige keus. En ik hoef dan echt niet vaker dan 1x of 2x per jaar de snapshots te controleren. De dataset is inderdaag vrijwel statisch. Bedankt voor de tip!!!

[Ceaus]

jan99999 schreef op zaterdag 18 januari 2025 @ 23:16:
Foto's ook op andere computers eens openen, of andere photo viewer.
Als de fout zeer minimaal is, dan zou het mogelijk kunnen zijn, dat als je veel photo viewer gebruikt, dat er 1 het wel goed opent, dit is me gelukt met een zeer oude photo viewer, daarna via deze programma weer opgeslagen.

Als je een backup maakt , ook altijd een backup programma gebruiken,die ook de origineel en kopie vergelijkt, tijdens backup maken, en ja dit duurt zeer lang. Dus niet een kopie maken met de verkenner.
Freefilesync is een gratis programma, waar je een backup mee kunt maken maar ook sync(kopie) maken, maar met bit by bit controle. Ook 2 hd's die hetzelfde zijn kun je bit by bit controleren.

Ook om problemen te voorkomen, doe dit op je hardware te testen:
Maak van vele iso files, een par2, dan kun je meerdere van deze files, over netwerk sturen, en dan de par2 laten lopen, om te checken of netwerk goed werkt. Stuur dus heel veel GB tegenlijk om alles flink te belasten.
Via netwerk heb ik eens gezien dat 1 op de 10 files fout was, en er van de pc geen foutmelding kwam.
En je weet, je gebruikt bijna nooit je backup, dus een fout zul je niet merken.

Dit kun je natuurlijk ook doen op een externe schijf om te checken of deze goed werkt.
Een nieuwe hd doe ik bijv smart bekijken, schijf vol schrijven, par2 checken, en weer smart bekijken of schijf nog goed is. Natuurlijk ook ssd en usb stick zo testen/belasten of ze goed werken.

Het gaat wel richting off-topic nu. En je doet ook aannames over het platform waar ik op zit, de tool sets die ik gebruik en mijn kennis niveau. En waarom je iso files erbij haalt begrijp ik ook niet.Photo viewer zegt me niks.

[Ceaus]

MAX3400 schreef op zaterdag 18 januari 2025 @ 11:56:
[...]

ECC heeft weinig tot niets te maken met (uiteindelijk) het gebruikte filesystem dus verdiep je er toch eens in?

ECC memory is de basis waarmee elke handeling op de betreffende machine "vlekkeloos" via het RAM gecontroleerd en uitgevoerd kan worden (hele basic uitleg). Echter neemt dat nog steeds niet weg dat zodra er een bestand wijzigt tijdens create/modify/delete, bijna in alle gevallen door externe factoren, dat dus niet wordt opgevangen door ECC (want daar is het niet voor bedoeld).

Een en ander wordt vast duidelijker als je het OSI-model raadpleegt; er zijn tientallen uren te discussieren hierover

Nou voorruit, tegen mijn eerdere belofte in toch maar een reactie: Ik lees een hele hoop aannames.

[BrainCrash]

Ceaus schreef op zaterdag 18 januari 2025 @ 10:18:
[...]
Het zijn oude Canon CR2 bestanden.

Dat zijn dus bestanden die door de meeste besturingssystemen wellicht niet native ondersteund worden.

Je schrijft niet op welke manier je de fotos nu bekijkt.. Met welk besturingssysteem, en met welk fotoviewer programma?

Op je screenshot is ook niet te zien welk programma je gebruikt om de fotos te bekijken, maar afgaande op de zichtbare buttons lijkt het een ingebouwde viewer van het besturingssysteem te zijn, óf een hele simpele algemene viewer.
Grote kans dat zo’n viewer die oude bestanden gewoon niet goed snapt, en die dus niet goed kan weergeven, met dergelijke weergavefouten als gevolg.
(De meeste snappen sowieso al geen camera RAW files, laat staan hele oude varianten hiervan)

Heb je het niet al eens geprobeerd te openen met Canon eigen RAW viewer of editing software?
Of met iets als Lightroom, of Darktable of zo?
De “professionelere” programma’s, zeg maar?
Hoe ziet er dat uit?

[jeroen3]

Is ook wel een rare corruptie hoor. Meestal zijn foto formaten cartografisch, maar hier lijkt er corruptie te zijn in de kolommen en rijen.

[Ceaus]

BrainCrash schreef op zondag 19 januari 2025 @ 10:02:
[...]


Dat zijn dus bestanden die door de meeste besturingssystemen wellicht niet native ondersteund worden.

Je schrijft niet op welke manier je de fotos nu bekijkt.. Met welk besturingssysteem, en met welk fotoviewer programma?

Op je screenshot is ook niet te zien welk programma je gebruikt om de fotos te bekijken, maar afgaande op de zichtbare buttons lijkt het een ingebouwde viewer van het besturingssysteem te zijn, óf een hele simpele algemene viewer.
Grote kans dat zo’n viewer die oude bestanden gewoon niet goed snapt, en die dus niet goed kan weergeven, met dergelijke weergavefouten als gevolg.
(De meeste snappen sowieso al geen camera RAW files, laat staan hele oude varianten hiervan)

Heb je het niet al eens geprobeerd te openen met Canon eigen RAW viewer of editing software?
Of met iets als Lightroom, of Darktable of zo?
De “professionelere” programma’s, zeg maar?
Hoe ziet er dat uit?

Darktable laat hetzelfde probleem zien. Maar daarvan weet ik ook niet precies hoe de CR2 decoder er aan is geknoopt. Intern? Via een externe library?
Maar los daar van, het gaat me eerlijk gezegd specifiek over ZFS. Of ik ZFS goed heb in gezet en daarover geen verkeerde aannames doe. De root-cause voor dit soort image problemen zijn relevant en interessant, dat wel Maar één ding tegelijk.

[Ceaus]

jeroen3 schreef op zondag 19 januari 2025 @ 10:04:
Is ook wel een rare corruptie hoor. Meestal zijn foto formaten cartografisch, maar hier lijkt er corruptie te zijn in de kolommen en rijen.

Ja, is ook zo. Voorlopig hou ik het erop dat het een viewer/CR2 library probleem is en dat het niet aan ZFS ligt. En dat is voor nu het belangrijkste. Misschien mag ik heel voorizchtig zelfs de conclusie trekken dat er daarom niks met de bestanden aan de hand is
Hier nog een setje thumbnails:

[BrainCrash]

Ceaus schreef op zondag 19 januari 2025 @ 10:09:
[...]
het gaat me eerlijk gezegd specifiek over ZFS. Of ik ZFS goed heb in gezet en daarover geen verkeerde aannames doe. De root-cause voor dit soort image problemen zijn relevant en interessant, dat wel Maar één ding tegelijk.

Volgens je topicstart gaat het je juist specifiek over je corrupte foto’s.
Dat het aan ZFS ligt is volgens mij een aanname die je zelf doet, en waar vooralsnog geen concrete aanwijzingen voor zijn. Hierdoor plaats je jezelf direct in een tunnelvisie zonder naar andere oorzaken te zoeken.
Zoals al genoemd is het immers uitermate vreemd dat filesystem corruptie op precies dezelfde manier plaatsvind over meerdere bestanden, en ook alleen maar op bestanden van één specifiek bestandstype..
Hoezo zou dat dan aan ZFS liggen?

Als je op één ding tegelijk wilt focussen, zou ik het juist zoeken in de root-cause van je image problemen… Daar gaat het je toch juist om? Dat ís toch het hele probleem?

[BrainCrash]

Ceaus schreef op zondag 19 januari 2025 @ 10:20:
[...]

Ja, is ook zo. Voorlopig hou ik het erop dat het een viewer/CR2 library probleem is en dat het niet aan ZFS ligt. En dat is voor nu het belangrijkste. Misschien mag ik heel voorizchtig zelfs de conclusie trekken dat er daarom niks met de bestanden aan de hand is
Hier nog een setje thumbnails:
[Afbeelding]

Je zou op de makkelijke manier gewoon 1 Raw file kunnen delen en aan de mensen hier vragen of ze die kunnen openen.
Je zit zo te zien niet op Windows?
Kan best dat Darktable idd dezelfde library gebruikt als je imageviewer (is dat Gwenview op KDE?)

[Ceaus]

BrainCrash schreef op zondag 19 januari 2025 @ 10:22:
Volgens je topicstart gaat het je juist specifiek over je corrupte foto’s.
Dat het aan ZFS ligt is volgens mij een aanname die je zelf doet, en waar vooralsnog geen concrete aanwijzingen voor zijn. Hierdoor plaats je jezelf direct in een tunnelvisie zonder naar andere oorzaken te zoeken.

Dan heb ik me niet zorgvuldig genoeg uitgedrukt (of je interpreteert teveel )
Nee, de vraag gaat daadwerkelijk over welke rol ZFS hierin zou kunnen spelen. Dat ik een aantal foto's erbij pak komt omdat die zo makkelijk toegankelijk zijn en het probleem daarbij zo zichtbaar is. Als ik dit soort ellende ook in mijn administratie heb, dan heb ik een fors probleem. Maar dat is nauwelijks zichtbaar. Hoe vaak kijk je tenslotte naar een factuur of een contract van 7 jaar oud.

[Ceaus]

BrainCrash schreef op zondag 19 januari 2025 @ 10:27:
Je zou op de makkelijke manier gewoon 1 Raw file kunnen delen en aan de mensen hier vragen of ze die kunnen openen.

J*z*s, waarom zit ik zo moeilijk te doen als het zo makkelijk kan Kost me 20 IQ punten Ik ga een berichtje op een grafisch forum posten.

Je zit zo te zien niet op Windows?
Kan best dat Darktable idd dezelfde library gebruikt als je imageviewer (is dat Gwenview op KDE?)

Yup.

[BrainCrash]

Ceaus schreef op zondag 19 januari 2025 @ 10:52:
[...]
Ik ga een berichtje op een grafisch forum posten.

Post je hier later nog wel even wat eruit gekomen is?

(En we hebben hier ook een fotografie subforum natuurlijk hè )

[Stanton]

Lijken ofwel bit errors of bestand is 'afgekapt' (is bestandsgrootte vergelijkbaar met vergelijkbare bestanden?). Anyway, typisch voor corrupt CR2 bestand.

Je zou een paar bestanden kunnen delen (en niet de plaatjes van de bestanden).

Maar is ws. niet te repareren, je kunt wellicht wel de preview JPEG extracten (kan met gratis JpegSnoop bijvoorbeeld).

[ Voor 8% gewijzigd door Stanton op 22-01-2025 20:00 ]

[Ceaus]

BrainCrash schreef op zondag 19 januari 2025 @ 14:55:
Post je hier later nog wel even wat eruit gekomen is?

Aye, aye kapitein!

Corrupte Canon CR2 foto's?

De bestanden zijn toch zelf corrupt. Dat betekent dat mijn ZFS setup goed is. Dat is dan wel een hele opluchting. Ik heb nu werkelijk geen idee wanneer de foto's gecorrumpeerd zijn geraakt. Maar ik heb nu wel sinds gisteren een baseline ZFS snapshot op mijn foto dataset. Dus dit gebeurt me niet nog een keer!

[BrainCrash]

Wel jammer van de corrupte fotos natuurlijk... (of had je nog ergens een oudere backup?)

Wel weer een kleine mazzel dat die RAW files blijkbaar embedded previews ingebakken hebben van maar liefst 2256 x 1504 pixels.... Oftewel 3,4Mpix. Dat kun je geen 'thumbnail' meer noemen natuurlijk, en is gezien de omstandigheden een heel stuk beter dan 'niks' meer hebben..

Ik had je samples ook nog even in Lightroom gegooid.. Ook daar vergelijkbare corruptie nadat het hele bestand ingelezen wordt. De 3.4Mpix preview is overgens inderdaad gewoon geheel viewable met Irfanview (bijvoorbeeld), en kun je dus ook vast wel op de een of andere manier untouched extracten van de originele corrupte file..

[Ceaus]

BrainCrash schreef op vrijdag 24 januari 2025 @ 15:15:
Wel jammer van de corrupte fotos natuurlijk... (of had je nog ergens een oudere backup?)

Nee, geen andere backup meer. Maar deze waren gelukkig niet erg belangrijk. In 2015 wilde ik nog van elk Italiaans grassprietje een foto maken. En nu achteraf is het een van een hele trits dezelfde

Wel weer een kleine mazzel dat die RAW files blijkbaar embedded previews ingebakken hebben van maar liefst 2256 x 1504 pixels.... Oftewel 3,4Mpix. Dat kun je geen 'thumbnail' meer noemen natuurlijk, en is gezien de omstandigheden een heel stuk beter dan 'niks' meer hebben..

Zeker, dat is indrukwekkende grootte voor een preview!