[Linux] Swap integriteit?

[DieterVDW]

Hallo,

Ik had net een groot Java proces dat een tijdje idle was, en bij resumen een segfault in de JVM gaf.
Dit leidde me tot de volgende bedenking: hoe waarschijnlijk is het dat geheugendata corrupt geraakt door disk IO fouten tijdens het swappen?
Wordt er enige vorm van integriteitscheck gedaan bij het weer inswappen van geheugen?

Search queries met 'linux swap integrity' leveren bitter weinig op, maar ik vermoed dat er hier wel een hardcore linux guru rondloopt die hier meer kan over vertellen?

[begintmeta]

man mkswap

en dan kijken wat optie -c doet.

hmm, je vraag niet helemaal goed begrepen denk ik, vziw wordt geen integriteitscheck gedaan, testen hoeveel fouten optreden bij disk-io is misschien een idee als je denkt dat dat een oorzaak kan zijn.

[ Voor 70% gewijzigd door begintmeta op 12-02-2013 16:03 ]

[Hero of Time]

Als er IO fouten voorkomen op je swap, komen ze ook voor op andere plekken op je schijf. Zulke fouten duiden op falen van de hardware en zal je niet veel tegen kunnen doen.
Als je JVM crasht, krijg je ook een log entry, vaak in ~/.xsession-errors. Heel goed mogelijk dat er niets mis is met je systeem, alleen het programma is brak en bugged hierop.

[downtime]

DieterVDW schreef op dinsdag 12 februari 2013 @ 15:56:
Hallo,

Ik had net een groot Java proces dat een tijdje idle was, en bij resumen een segfault in de JVM gaf.
Dit leidde me tot de volgende bedenking: hoe waarschijnlijk is het dat geheugendata corrupt geraakt door disk IO fouten tijdens het swappen?
Wordt er enige vorm van integriteitscheck gedaan bij het weer inswappen van geheugen?

Search queries met 'linux swap integrity' leveren bitter weinig op, maar ik vermoed dat er hier wel een hardcore linux guru rondloopt die hier meer kan over vertellen?

Met een search op 'crc' of 'checksum' kom je misschien verder. Zover ik weet is dit een functie van de harddisk zelf en niet (alleen) het file system.

[Hero of Time]

downtime schreef op woensdag 13 februari 2013 @ 01:13:
[...]

Met een search op 'crc' of 'checksum' kom je misschien verder. Zover ik weet is dit een functie van de harddisk zelf en niet (alleen) het file system.

Waar moet je de crc of andere checksum dan mee verifiëren? Swap space is overigens niet een file system an sich zoals een file system zich zou gedragen. Het is een uitbreiding van je fysiek geheugen en data in swap is ruw op de schijf. Er zit geen directe logica in zoals een FS dat wel heeft. Enige logica die er is, is verwijzingen naar blokken op de schijf voor geheugen allocatie.

[downtime]

Hero Of Time schreef op woensdag 13 februari 2013 @ 20:52:
Waar moet je de crc of andere checksum dan mee verifiëren?

Leesvoer: Wikipedia:

Error handling

Modern drives make extensive use of error correction codes (ECCs), particularly Reed–Solomon error correction. These techniques store extra bits, determined by mathematical formulas, for each block of data; the extra bits allow many errors to be corrected invisibly. The extra bits themselves take up space on the HDD, but allow higher recording densities to be employed without causing uncorrectable errors, resulting in much larger storage capacity.[25] In the newest drives of 2009, low-density parity-check codes (LDPC) were supplanting Reed-Solomon; LDPC codes enable performance close to the Shannon Limit and thus provide the highest storage density available.[26]

Typical HDDs attempt to "remap" the data in a physical sector that is failing to a spare physical sector—hopefully while the errors in the bad sector are still few enough that the ECC can recover the data without loss. The S.M.A.R.T-Self-Monitoring, Analysis and Reporting Technology system counts the total number of errors in the entire HDD fixed by ECC and the total number of remappings, as the occurrence of many such errors may predict HDD failure.

Nog wat links:
http://www.pcguide.com/ref/hdd/geom/error_ECC.htm
http://computer-forensics...ery-ecc-data-and-recovery

[deadinspace]

Voorzover ik weet ondersteunt Linux geen integriteitscontrole op swap. Ik heb wel een patch gevonden die precies dat toevoegt, maar ik heb nogal het idee dat die (nog) niet in mainline is opgenomen. Ik ben wel benieuwd wat de status van die patch precies is, maar dat kon ik zo snel niet vinden

Hero Of Time schreef op dinsdag 12 februari 2013 @ 16:56:
Als er IO fouten voorkomen op je swap, komen ze ook voor op andere plekken op je schijf. Zulke fouten duiden op falen van de hardware en zal je niet veel tegen kunnen doen.

Dat klopt, maar met een checksum oid weet je het tenminste en voorkom je ongemerkte corrupte data. Sommige filesystems (zoals ZFS en btrfs) checksummen hun data ook precies om die reden.

downtime schreef op woensdag 13 februari 2013 @ 21:25:
Leesvoer: Wikipedia:
[...]

Jawel, maar dan ga je er van uit dat de harde schijf geen fouten maakt daarmee. En hardware (zeker goedkoop consumentenspul) is daarmee niet te vertrouwen.

Als bijvoorbeeld een sector niet weggeschreven wordt door de schijf om wat voor reden dan ook (terwijl dat wel zou moeten), dan heb je niks aan die hele ECC. Je krijgt bij het lezen dan namelijk gewoon de oude sector compleet met bijbehorende oude ECC. Volgens de harde schijf is er niks aan de hand, maar het OS krijgt een sector met swap of file-data terug die niet (meer) klopt...

Ik vind dergelijke checksumming in software daarom een goed iets, ik vertrouw die schijven voor geen meter

[downtime]

deadinspace schreef op donderdag 14 februari 2013 @ 00:10:
Jawel, maar dan ga je er van uit dat de harde schijf geen fouten maakt daarmee. En hardware (zeker goedkoop consumentenspul) is daarmee niet te vertrouwen.

Ik ga nergens van uit. Checksums moeten op meerdere niveau's gemaakt worden en daarbij mogen hardware en firmware zeker niet ontbreken. Het is niet erg efficient om alles in software te doen.

[DieterVDW]

Vraag is natuurlijk: wat doe je als je detecteert dat een swap pagina corrupt terugkomt?
Harde crash?

[CyBeR]

Zet je swap op ZFS.

[Hero of Time]

downtime schreef op woensdag 13 februari 2013 @ 21:25:
[...]

Leesvoer: Wikipedia:

[...]

Nog wat links:
http://www.pcguide.com/ref/hdd/geom/error_ECC.htm
http://computer-forensics...ery-ecc-data-and-recovery

Ja, leuk, ECC. Heeft heel veel zin op je HDD met swap Daarbij heeft de TS geen specs gegeven, dus gaan we uit van een consumenten PC, geen server.

Zoals hierboven al is uitgelegd, checksums zijn leuk, maar als 't al verkeerd weggeschreven wordt, heb je niets om op terug te vallen om aan te geven waar het fout gaat (is het foute data, is de HDD rot, noem maar op).

[H!GHGuY]

Er wordt ook gewerkt aan end-to-end validation van data. Op dit moment berekent de HDD zelf de ECC die hij wegschrijft en kan het OS zelf ook een ECC berekenen en wegschrijven, maar als je data rot wordt wanneer hij over een brakke kabel loopt heb je er niets aan.

Het doel van dit feature is om op z'n minst CRC data mee te geven aan de hardware zodat brakke kabels kunnen uitgesloten worden en je een volledige validatie krijgt van memory->disk.

Dit zal wsch wel nog niet weggelegd zijn voor commodity SATA drives...

[downtime]

Hero Of Time schreef op donderdag 14 februari 2013 @ 11:49:
Ja, leuk, ECC. Heeft heel veel zin op je HDD met swap Daarbij heeft de TS geen specs gegeven, dus gaan we uit van een consumenten PC, geen server.

ECC is standaard functionaliteit in alle HDD's. Moet ook, anders zou je fouten nooit kunnen detecteren.

Zoals hierboven al is uitgelegd, checksums zijn leuk, maar als 't al verkeerd weggeschreven wordt, heb je niets om op terug te vallen om aan te geven waar het fout gaat (is het foute data, is de HDD rot, noem maar op).

Om die reden worden checksums op meerdere niveau's gemaakt zodat wel duidelijk is waar het mis gaat.

H!GHGuY schreef op donderdag 14 februari 2013 @ 12:15:
Er wordt ook gewerkt aan end-to-end validation van data. Op dit moment berekent de HDD zelf de ECC die hij wegschrijft en kan het OS zelf ook een ECC berekenen en wegschrijven, maar als je data rot wordt wanneer hij over een brakke kabel loopt heb je er niets aan.

Niet dus. Ook aan data die over de kabel wordt verstuurd worden checksums toegevoegd om overdrachtsfouten te detecteren. Fouten zijn namelijk onvermijdelijk, ook in goed werkende apparatuur, en ze moeten gedetecteerd worden zodat de corrupte data opnieuw verstuurd kan worden.

Het doel van dit feature is om op z'n minst CRC data mee te geven aan de hardware zodat brakke kabels kunnen uitgesloten worden en je een volledige validatie krijgt van memory->disk.

Dit zal wsch wel nog niet weggelegd zijn voor commodity SATA drives...

Is altijd al standaard functionaliteit geweest.

[deadinspace]

downtime schreef op donderdag 14 februari 2013 @ 00:30:
Ik ga nergens van uit. Checksums moeten op meerdere niveau's gemaakt worden en daarbij mogen hardware en firmware zeker niet ontbreken.

Nouja, je zei dat integriteitscontrole een functie is van de harde schijf. Ik wil daar de kanttekening bij plaatsen dat als je uit wil gaan van die functionaliteit van de harde schijf je dat ding wel moet kunnen vertrouwen

Het is niet erg efficient om alles in software te doen.

Ach. Als ik benchmarks als deze en deze mag geloven dan doet een moderne CPU (een i5 ofzo) 1.5GB/s aan CRC32. Met SSE4.2 gaat dat zelfs naar 4GB/s. Dat is nogal wat, en als dat je garantie geeft op niet-corrupte data dan kan dat beetje extra overhead best de moeite zijn.

DieterVDW schreef op donderdag 14 februari 2013 @ 09:49:
Vraag is natuurlijk: wat doe je als je detecteert dat een swap pagina corrupt terugkomt?
Harde crash?

Dan geef je het proces waar die pagina bij hoort SIGBUS (of evt SIGSEGV), en je logt dat er een corrupte pagina uit de swap is gekomen (compleet met sectornummers etc).

De voordelen zijn dat het betrouwbaar fout gaat (het proces krijgt SIGBUS ipv dat random troep probeert uit te voeren) en dat je WEET wat het probleem is.

CyBeR schreef op donderdag 14 februari 2013 @ 11:48:
Zet je swap op ZFS.

Linux swapfles bypassen het filesystem volledig. Voor de kernel is een swapfile gewoon een lijst blocks waarop rechtstreeks I/O gedaan wordt. ZFS checksumming heeft dus geen effect op swapfiles.

Hero Of Time schreef op donderdag 14 februari 2013 @ 11:49:
Ja, leuk, ECC. Heeft heel veel zin op je HDD met swap Daarbij heeft de TS geen specs gegeven, dus gaan we uit van een consumenten PC, geen server.

Harde schijven hebben zelf ook ECC, dat is waar downtime het over had

H!GHGuY schreef op donderdag 14 februari 2013 @ 12:15:
Op dit moment berekent de HDD zelf de ECC die hij wegschrijft en kan het OS zelf ook een ECC berekenen en wegschrijven, maar als je data rot wordt wanneer hij over een brakke kabel loopt heb je er niets aan.

Als het OS zelf een checksum of ECC berekent dan heb je daar wel degelijk wat aan als de data over een brakke kabel gaat natuurlijk

[DieterVDW]

deadinspace schreef op donderdag 14 februari 2013 @ 14:24:
Dan geef je het proces waar die pagina bij hoort SIGBUS (of evt SIGSEGV), en je logt dat er een corrupte pagina uit de swap is gekomen (compleet met sectornummers etc).

Is een swap-pagina gebonden aan slechts 1 proces? Of kan een pagina data van meerdere processen bevatten?

[Hero of Time]

DieterVDW schreef op donderdag 14 februari 2013 @ 15:47:
[...]


Is een swap-pagina gebonden aan slechts 1 proces? Of kan een pagina data van meerdere processen bevatten?

Kan een process het geheugen van een ander manipuleren? Als je zegt 'ja', dan heb je een serieus probleem, en niet alleen voor security redenen. Een page is van een process en niets anders. Zo hoort het iig, tenzij er een bug in de software is die het toestaat dat andere processen met z'n geheugen mag rommelen.

[CyBeR]

Shared memory

[deadinspace]

DieterVDW schreef op donderdag 14 februari 2013 @ 15:47:
Is een swap-pagina gebonden aan slechts 1 proces? Of kan een pagina data van meerdere processen bevatten?

Zo intiem bekend ben ik nou ook weer niet met Linux VM

Zoals CyBeR terecht opmerkt kunnen pagina's gedeeld worden tussen processen, en niet alleen door expliciet gedeeld geheugen, ook executable code uit hetzelfde programma wordt gedeeld tussen processen, en als een proces een kopie van zichzelf start delen ze (initieel) vrijwel alle pagina's. Ik neem aan dat als zo'n gedeelde pagina uitgeswapt wordt hij nog steeds tot meerdere processen behoort. In het geval van een checksum failure op zo'n pagina zouden al die processen dus beeindigd moeten worden.

De vraag is een beetje: wat gebeurt er als de kernel een pagina probeert in te swappen en de harde schijf geeft een I/O error? Datzelfde zou ook moeten gebeuren als de harde schijf wel een pagina teruggeeft maar Linux' checksum faalt.

[H!GHGuY]

downtime schreef op donderdag 14 februari 2013 @ 14:23:
Niet dus. Ook aan data die over de kabel wordt verstuurd worden checksums toegevoegd om overdrachtsfouten te detecteren. Fouten zijn namelijk onvermijdelijk, ook in goed werkende apparatuur, en ze moeten gedetecteerd worden zodat de corrupte data opnieuw verstuurd kan worden.
[...]
Is altijd al standaard functionaliteit geweest.

Ik had het over:
http://www.kernel.org/doc.../block/data-integrity.txt
Hiervoor heb je wel degelijk extra support nodig.

deadinspace schreef op donderdag 14 februari 2013 @ 14:24:
Als het OS zelf een checksum of ECC berekent dan heb je daar wel degelijk wat aan als de data over een brakke kabel gaat natuurlijk

Ja, maar:
- je disk weet niet dat de data die hij opslaat fout is
- je OS weet pas dat er een fout is lang nadat de data is weggeschreven (en dus de fout niet meer recoverable is)

Dat zijn de problemen die het data integrity feature oplossen:
Je OS maakt een checksum en die kan door de controller en je drive geverifieerd worden. Als er dan een fout optreedt, is de data nog voorhanden en kan corruptie voorkomen worden.

[ Voor 37% gewijzigd door H!GHGuY op 15-02-2013 12:46 ]