[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: verifiering av filer



On 2011-12-31 15:00, jan@lillahusetiskogen.se wrote:
On Sat, 31 Dec 2011 05:46:19 +0100
Anders Jackson <anders.jackson@gmail.com> wrote:

Den 30 december 2011 11:29 skrev  <jan@lillahusetiskogen.se>:
On Fri, 30 Dec 2011 01:56:04 +0100
Anders Jackson <anders.jackson@gmail.com> wrote:
Den 29 december 2011 12:25 skrev  <jan@lillahusetiskogen.se>:

        
Jag håller på och kopierar filer mellan två diskar och använder
md5sum för att verifiera att det gick bra.
Varför använder du inte det utmärkta programmet rsync(1) för detta?
Utmärkt att ta backup mellan två ställen, om det är på samma maskin
eller två olika spelar inte någon roll.
Alldeles utmärkt program. Och, jo jag använder det.

Grejen är den att jag för mina "samlingar" brukar ha två kopior för
säkerhets skull och använder md5 för att kunna verifiera att dom är
OK. Vad är nyttan med två kopior som är olika om man inte vet
vilken som är trasig?
Även om de är lika så kan de ju vara trasiga.  Om "orginalet" är
trasig så kommer ju kopian åxå vara det.
Skit händer som bekant.

Det kan hända på hårddiskar, och med så stora som vi har idag, så är
risken ganska hög.  För att skydda mot detta så behöver du ett
filsystem som exempelvis ZFS, som är riktigt enkelt att kopiera säkert
mellan två olika ZFS-filsystem.
ZFS låter ju bra men verkar inte riktigt moget för Linux än.

Och kommer kanske aldrig bli på grund av licenskrocken mellan CDDL som ZFS använder och GNU GPL som linuxkärnan använder. Btrfs å andra sidan har ju ibland beskrivits som "ZFS för Linux", men det är väl inte heller riktigt moget än.

      
Sedan så kollar ju rsync om bägge sidor är lika med checksummor redan,
så det behöver du ju inte göra igen.
Om du vill vara säkerare, så kör sync och sedan rsync igen.  Är
totalstorleken på filerna så stort att de inte ryms i ram-buffertarna,
så kommer RAm-buffertarna att skrivas över av innehållet från diskarna
när nya delar läses in. Och rsync checka vad som finns på disken, inte
i RAM-buffertarna.

Så jag förstår inte problemet, faktiskt.
Grejen är den att har man en md5-fil (eller ännu hellre en bättre hash)
så kan man avgöra om båda eller ena eller ingen av filerna är
"identisk" med den fil man hade från början. Idag, imorgon, nästa år...
Eller så går md5-filen sönder...


        
Efter att ha suttit och stirrat på skeendet ett tag inser jag att
md5sum kollar data som är buffrat i RAM om det finns
tillgängligt, inte resultatet på disk. Mycket snabbt men
tämligen poänglöst.
Om du vill vara säker på att buffertarna töms till diskar, så
använd kommandot sync(1).
Jo jag vet. Nu var ju problemet det omvända. Linux hittar filerna i
buffrar i RAM och det är ju bra, oftast, men jag vill ju veta om
kopian på den fysiska disken blev OK.
Sync gör ju det.  Det ser till att innehållet i RAM-buffertarna skrivs
ut till filsystemet.
Japp, och det är ju bra. Men problemet är att md5sum använder
innehållet i RAM-buffertarna. Och, resultatet av det? Jag vet att
RAM-buffertarna var OK, men filerna på disken då?


        
Jag fick en bra länk från Anton:
http://www.go2linux.org/linux/2011/01/how-clear-or-drop-cache-buffer-pages-linux-memory-880
Jo, jag såg det.  Men förstår fortfarande inte varför det skulle vara
bättre än att använda sync?
Två olika problem.

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å.

      

        
Om du vill sync:a maskinens diskar utan att vara inloggad, så
försök att logga in som användaren sync.  Den kommer att köra
kommandot sync(1) och sedan avsluta anslutningen.

Finns det något sätt att tvinga program att läsa från disk istf
buffrade data i RAM?
Du kan fortfarande få odekteterade bitfel, om det är ett stort
filsystem och stora filer.  Såvida du inte använder ett filsystem typ
ZFS.
Jupp, som sagt, skit händer...


        
Gott nytt etc!
/Janne
Det samma!
/Jackson


/Janne




-- 
Med vänliga hälsningar / Regards
Anton Eliasson

Reply to: