Re: verifiering av filer
God fortsättning allal
Den 31 december 2011 15:39 skrev <jan@lillahusetiskogen.se>:
> On Sat, 31 Dec 2011 15:28:26 +0100 Anton Eliasson <anton.e.92@gmail.com> wrote:
>> För att utveckla: sync skriver innehållet i skrivbuffertarna till
>> disk omedelbart. Det påverkar inte läsbuffertarna. |echo 3 >
>> /proc/sys/vm/drop_caches| tömmer läs- och skrivbuffertarna utan att
>> ta hänsyn till om innehållet i skrivbuffertarna har skrivits till
>> disk eller inte. Det är därför det kommandot måste köras direkt efter
>> sync, för att inte information ska gå förlorad. Nu tror jag dock att
>> vi jagar upp oss på problem som inte finns, för sannolikt har de
>> flesta metoder för filkopiering inbyggda kontroller för att
>> säkerställa att rätt information kopieras. Sen finns det ju idéer om
>> bitröta i magnetiska lagringsmedier och korruption i
>> icke-ECC-internminnen som man kanske vill vara förberedd på.
>
> Jag är tyvärr smärtsamt medveten om att stora filer går sönder. Både
> vid kopiering mellan datorer och lokalt.
Riskerna för "bitröta" blir större, ju större minnen vi använder.
Det var bland annat för att lösa detta problem med hårddiskar som ZFS
ser ut som det gör. Läs om det, det finns många intressanta
blogg-inlägg skrivna om detta och om hur ZFS fungerar.
> Jag har sett det tidigare också men med Ubuntu 11.04 blev det riktigt
> tydligt. Tyvärr verkar problemet även, om än inte så allvarligt, finnas
> också i Mint Debian.
Tror inte att det har det minsta att göra med distributionernan, utan
möjligen version av kernel. Men allra mest med vilket filsystem man
använder och hur dessa är uppbyggda.
> Och varför kör jag då inte vanlig Debian, som kanske fungerar felfritt.
> Jo, min hårdvara Asus E35M1-I stöds inte fullt ut av Debian. Så vitt
> jag vet.
Ok, det är väl ett bra argument. Får man fråga vad det är? Om det är
firmware som inte existerar, så finns det massa icke-fria firmware
packeterade. Dessa kan dessutom användas när man installerar, bara
paketet finns på mediat (eller ett annat, som en USB-sticka).
> Gott nytt etc!
> /Janne
Önske dig som skriver det samma.
Så.
Jag tror inte alls att du behöver oroa dig för att md5 skall missa
något för att innehållet i RAM-bufferten är olikt innehållet på filens
sektor i disken. Speciellt om filerna är mycket större än
RAM-storleken och allt som kopieras inte kan finnas i minnet
samtidigt. OM du kopierar något som är mindre än buffertminnet, så
borde sync(1) räcka.
Men med stora datamängder så kommer ju md5sum att läsa genom filerna
för att kunna beräkna checksumman. Då måste innehållet i alla filerna
läsas in till RAM-minnet. Dvs läsa från disken, eftersom all data
inte får plats i RAM-buffertar. Då skulle inte ens behöva använda
sync(1) för att tvinga OS:et att tömma buffertarna till disken.
Vad som kan eventuellt möjligen bli fel är att OS:et skriver data till
disken men inte kontrollerar när det skriver att det är samma data som
kommer tillbaka. För detta behöver filsystemet implementera
checksummor på allt, samt att OS:et behöver kolla dem, från att
program skriver data i RAM:buffertar tills att de skrivs på disk, på
vägen tillbaka från disken och i RAM:buffertarna. Varje del måste
verifieras om du flyttar MYCKET data. Dvs du behöver stöd hela vägen.
OpenSolaris hade detta stöd med ZFS, Linux börjar få det iom btrfs,
men har en bit kvar.
Att använda MD5sum på alla filerna är ett bra sätt att minska risken
för en förändring av en fil som du inte märker av. Men att hantera de
fel som du vill undvika, är varken nödvändigt eller möjligt att
hantara med de vanligaste stora OS:en för konsumentdatorer. Vad jag
sett är väl Solaris det os som gjort mest för att hantera problem med
bitröta i stora diskar.
(Hmm, jag som tänkte skriva något kort... :D )
/Jackson
Reply to: