sslug-teknik team mailing list archive

[Henrik "St�" <henrik@xxxxxxx>]

In <134B8AAE635DD411BC8500508BDF754C08654259@xxxxxxxxxxxxxxx> Andreas Bjerre Overgaard <anov@xxxxxx> writes:

><cut>
>> dump er - iflg. Linus Torvalds - fuldst=E6ndig h=E5bl=F8s og=20
>> ubrugelig, og burde v=E6re forvist til de evige bit-marker. Jeg=20
>> tager hans ord for at det er en d=E5rlig ide at bruge det v=E6rkt=F8j =
>...
><cut>

>  Det er virkelig et godt argument jeg har spurgt 100 gange om hvad der =
>er i vejen med den og har aldrig f=E5et et svar, men her er det endelig.
>
>  Jeg har kun gode erfaringer med dump af hele diske.

Jeg fornemmer et svagt sarkastisk tilsnit i dit svar :-)

Nuvel - problemet skyldes at dump læser det "rå" block-device,
/dev/hda* /dev/sda*. Når der er åbne filer er nogle data imidlertid
cachet i forskellige dele af operativsystemet, og der er ikke
nødvendigvis overensstemmelse mellem den cache som filsystemets data
ligger i, og den cache som blok-devicens data ligger i.

Derfor kan dump - ved at gå uden om filsystemets normale tilgangs-måde
og filsystemets cache-data - læse data fra disken som er
inkonsistente. dump får simpelt hen ikke de opdateringer med, som
ligger i filsystemets cache.

Tidligere kunne det gå så galt at dump fik "forvirret" cache-data, så
man kunne risikere at få skrevet forkerte ext2 metadata til disken
efter at have kørt dump - d.v.s. din backup kunne resultere i et
ødelagt filsystem! Denne fejl er dog rettet, men du kan stadig få en
dårlig backup med dump.

Lav f.eks. en Google søgning på "dump+corrupt+ext2" og du vil finde en
stribe mails på kernel-listen, som fortæller om det.

http://hypermail.idiosynkrasia.net/linux-kernel/archived/2001/week41/0952.html
http://hypermail.idiosynkrasia.net/linux-kernel/archived/2001/week41/0851.html
http://www.cs.helsinki.fi/linux/linux-kernel/2001-40/1008.html
http://www.cs.helsinki.fi/linux/linux-kernel/2001-40/1002.html
-- 
Henrik Storner <henrik@xxxxxxx>