Door Anoniem: Vergeet niet dat er bij Flash memory niet gewerkt wordt met sectoren dus die FAT tabel wordt steeds op een andere (frisse plek afhankelijk van de hardware chip) weggeschreven.
Ik schreef "sectors" tussen aanhalingstekens omdat het natuurlijk niet gaat om taartpunten verdeeld in cirkelvormige ringen, maar er wordt wel met blokken gewerkt (die extern vaak 512 bytes groot zijn, de interne blokgrootte kan daarvan afwijken - wat weet extra slijtage tot gevolg kan hebben). En dat er met blokken i.p.v. sectors wordt gewerkt, betekent niet dat er dan "vanzelf" wear-leveling plaatsvindt.
SSD's zouden veel te snel onbruikbaar worden zonder wear-leveling
en het trim-commando, maar voor zover ik weet beschikken goedkope flash-memory kaartjes niet of nauwelijks over dit soort, best complexe, technieken. Je moet namelijk "onthouden" hoe vaak naar elk blok geschreven is, en ook moet je een vertaaltabel van virtueel naar fysiek blok bijhouden. Dat doe je natuurlijk ook in flash, maar hoe voorkom je dat
die gebieden te vaak worden beschreven?
Voor zover ik weet ondersteunt de aanvankelijke SD-kaart standaard bijv. het trim-commando niet (waarmee aan de controller in een flash-geheugen-device wordt meegedeeld dat blokken mogen worden hergebruikt nadat de gebruiker
op het niveau van het filesystem bestanden en/of mappen heeft "gewist" - wat in de praktijk meestal vrijgeven betekent zonder dat er iets "gewist"/overschreven wordt). Zonder trim-commando weet een vol
geweest device niet welke van de "voor de gebruiker beschikbare blokken" (de geheugencapaciteit zoals vermeld op het device, zonder overcapaciteit / spare blocks dus) zouden mogen worden hergebruikt, en moet dan gebruikmaken van de meestal aanwezige overcapaciteit. Maar als goedkope devices bijv. 10% overcapaciteit hebben, en slechts daarmee wordt uitgewisseld, wordt
daar weer relatief vaak naar geschreven.
Hoe het met moderne SDHC/SDXC kaartjes zit weet ik niet, maar ik heb zelf (omstreeks 2006) ononderbroken en "gemene" schrijftests uitgevoerd op 512MB Compact Flash kaartjes (ik meen van Sandisk, in elk geval een bekend merk); die gingen zo snel stuk dat we ze niet konden gebruiken voor onze toepassing (in een embedded systeem). En niet voor niets zijn er omstreeks die tijd filesystems bedacht die de "wear-leveling" taak naar de computer zelf verplaatsen.
Door Anoniem: Onder Linux zijn de checks tussen de 2 tables goed ingeregeld... volgens mij wordt er bij elke mount even gecontroleerd en anders een dirty bitje als ik me niet vergis...?
Ik kan me geen dirty-bit herinneren voor de oorspronkelijke FAT (12 bits op floppies en 16 bits op harddisks met museumleeftijd), maar misschien laat m'n geheugen me in de steek. Een probleem is in elk geval dat als er een verschil bestaat tussen die twee FAT-tabellen,
niet omdat de laatste van de twee niet meer geschreven kon worden (bijv. doordat de voeding te vroeg werd uitgezet of de floppy werd uitgeworpen), maar omdat er flash-bits zijn "omvallen", je niet zomaar weet
welke van de twee tabellen klopt (tools als chkdsk/fsck
kunnen in een deel van de gevallen uitsluitsel geven, maar je kunt ook zomaar met *.chk files eindigen of "files" in een map zoals lost+found, en bij gefragmenteerde filesysystems kunnen in een file zomaar blokken uit een andere -al dan niet gewiste- file verschijnen).
Door Anoniem: Een backup schrijf je naar nieuwe flashdisks of tenminste je herschrijft ze geen duizend keer want dan is het een "werkdisk".
Met name als je een file-based back-up maakt, worden die FAT-tabellen relatief heel vaak beschreven, dat is wat ik bedoelde (vooral als "delayed write" uit staat, wat bij Windows de standaard is voor FAT-formatted removable drives).
Door Anoniem: Ik heb nog SD memory in allerlei formaten van 20 jaar geleden die het prima doen. Vroeger zeiden ze over CDROMS (zelfgebrandde) dat ze na 5 jaar wel op zouden zijn "dus dan neem je liever die Philips"... nou na 20 jaar lezen ze nog prima uit. Ik heb een disk (nog met RLL codering) van een Vax. Dat ding is 500mb en weegt wel een paar kilo. Ondertussen 30 jaar oud. Hij is nog intact. De andere schijven ook.
Diezelfde ervaring heb ik ook. Maar een redelijke zekerheid dat je bijv. een WDAC31600 (1.6GB) HDD (van tig jaar geleden) die het
vandaag nog doet, ook
morgen nog kunt uitlezen, heb je natuurlijk niet.