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

Re: verifiering av filer



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.

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

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


Reply to: