God fortsättning allal Den 31 december 2011 15:39 skrev <[email protected]>: > On Sat, 31 Dec 2011 15:28:26 +0100 Anton Eliasson <[email protected]> > 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/cacxj-bg+kskg7xxdzztauqqrxajd_oaaz_ehyjxseuo4bcy...@mail.gmail.com
