---

Windows installer har fået fucket op i min partitions tabel på sda.

Og så kunne den ikke engang få win installeret, så jeg har måtte installere
Linux Mandriva på en tom partition, der tog jeg så resten af hdc.
Under install af Mandriva skrev den, at partitions tabellen er for
beskadiget til den kan rede den, og spurgte om den skulle slette alt, eller
låse sda, så den ikke laver flere skader på den.

Jeg kan godt mounte partitionerne, og også godt læse indholdet.

Jeg vil derfor godt have en total backup af indholdet, så jeg kan slette
alle partitioner, og oprette nogle nye, og restore backupperne.

Jeg er dog usikker på hvordan jeg skal gøre.
Det jeg er mest usikker på, det er at jeg ikke får lavet om på ejerskabet af
nogle filer. Samt at jeg er i stand til at boote på mit gamle system.

Jeg vil godt benytte lejligheden til at ryde op i partitionerne, der er 2
som skal forblive uændret, men gerne skulle blive støre, og resten er der
bare nogle få filer som skal bevares, dem har jeg tænkt på bare at kopiere
over på en af dem der skal forblive.

Hvad laver jeg backuppen med? dd kan vel ikke bruges, når der skal ændres
på størelsen af partitionen ved restore.




--
Mvh

Ivar

---

news.cybercity.dk@milli.dk wrote:
> Windows installer har fået fucket op i min partitions tabel på sda.
>
> Og så kunne den ikke engang få win installeret, så jeg har måtte installere
> Linux Mandriva på en tom partition, der tog jeg så resten af hdc.
> Under install af Mandriva skrev den, at partitions tabellen er for
> beskadiget til den kan rede den, og spurgte om den skulle slette alt, eller
> låse sda, så den ikke laver flere skader på den.
>
> Jeg kan godt mounte partitionerne, og også godt læse indholdet.
>
> Jeg vil derfor godt have en total backup af indholdet, så jeg kan slette
> alle partitioner, og oprette nogle nye, og restore backupperne.
>
> Jeg er dog usikker på hvordan jeg skal gøre.
> Det jeg er mest usikker på, det er at jeg ikke får lavet om på ejerskabet af
> nogle filer. Samt at jeg er i stand til at boote på mit gamle system.
>
> Jeg vil godt benytte lejligheden til at ryde op i partitionerne, der er 2
> som skal forblive uændret, men gerne skulle blive støre, og resten er der
> bare nogle få filer som skal bevares, dem har jeg tænkt på bare at kopiere
> over på en af dem der skal forblive.
>
> Hvad laver jeg backuppen med? dd kan vel ikke bruges, når der skal ændres
> på størelsen af partitionen ved restore.
>
>
>
>

Hvis du bruger dd på /dev/sda2 (f.eks.) i stedet for /dev/sda ved jeg
ikke om størrelsen følger med.

---

Jesper Staun Hansen wrote:

> news.cybercity.dk@milli.dk wrote:
>> Windows installer har fået fucket op i min partitions tabel på sda.
>>
>> Og så kunne den ikke engang få win installeret, så jeg har måtte
>> installere Linux Mandriva på en tom partition, der tog jeg så resten af
>> hdc. Under install af Mandriva skrev den, at partitions tabellen er for
>> beskadiget til den kan rede den, og spurgte om den skulle slette alt,
>> eller låse sda, så den ikke laver flere skader på den.
>>
>> Jeg kan godt mounte partitionerne, og også godt læse indholdet.
>>
>> Jeg vil derfor godt have en total backup af indholdet, så jeg kan slette
>> alle partitioner, og oprette nogle nye, og restore backupperne.
>>
>> Jeg er dog usikker på hvordan jeg skal gøre.
>> Det jeg er mest usikker på, det er at jeg ikke får lavet om på ejerskabet
>> af nogle filer. Samt at jeg er i stand til at boote på mit gamle system.
>>
>> Jeg vil godt benytte lejligheden til at ryde op i partitionerne, der er
>> 2 som skal forblive uændret, men gerne skulle blive støre, og resten er
>> der bare nogle få filer som skal bevares, dem har jeg tænkt på bare at
>> kopiere over på en af dem der skal forblive.
>>
>> Hvad laver jeg backuppen med? dd kan vel ikke bruges, når der skal ændres
>> på størelsen af partitionen ved restore.
>>
>>
>>
>>
>
> Hvis du bruger dd på /dev/sda2 (f.eks.) i stedet for /dev/sda ved jeg
> ikke om størrelsen følger med.


[root@localhost mnt]# dd if=/dev/sda1 of=/dev/sda11
29977227+0 records in
29977227+0 records out
15348340224 bytes (15 GB) copied, 3372,5 s, 4,6 MB/s


Og sda11 kan ikke læses. Så det dutter ikke.

Hvad med tar -cj

--
Mvh

Ivar

---

Ivar Madsen <news.cybercity.dk@milli.dk> writes:

> [root@localhost mnt]# dd if=/dev/sda1 of=/dev/sda11
> 29977227+0 records in
> 29977227+0 records out
> 15348340224 bytes (15 GB) copied, 3372,5 s, 4,6 MB/s

dd kan godt skrive til en fil, behøver ikke være en hel disk.

--
Thorbjørn Ravn Andersen

---

Ivar Madsen wrote:
> Jesper Staun Hansen wrote:
>
>> news.cybercity.dk@milli.dk wrote:
>>> Windows installer har fået fucket op i min partitions tabel på sda.
>>>
>>> Og så kunne den ikke engang få win installeret, så jeg har måtte
>>> installere Linux Mandriva på en tom partition, der tog jeg så resten af
>>> hdc. Under install af Mandriva skrev den, at partitions tabellen er for
>>> beskadiget til den kan rede den, og spurgte om den skulle slette alt,
>>> eller låse sda, så den ikke laver flere skader på den.
>>>
>>> Jeg kan godt mounte partitionerne, og også godt læse indholdet.
>>>
>>> Jeg vil derfor godt have en total backup af indholdet, så jeg kan slette
>>> alle partitioner, og oprette nogle nye, og restore backupperne.
>>>
>>> Jeg er dog usikker på hvordan jeg skal gøre.
>>> Det jeg er mest usikker på, det er at jeg ikke får lavet om på ejerskabet
>>> af nogle filer. Samt at jeg er i stand til at boote på mit gamle system.
>>>
>>> Jeg vil godt benytte lejligheden til at ryde op i partitionerne, der er
>>> 2 som skal forblive uændret, men gerne skulle blive støre, og resten er
>>> der bare nogle få filer som skal bevares, dem har jeg tænkt på bare at
>>> kopiere over på en af dem der skal forblive.
>>>
>>> Hvad laver jeg backuppen med? dd kan vel ikke bruges, når der skal ændres
>>> på størelsen af partitionen ved restore.
>>>
>>>
>>>
>>>
>> Hvis du bruger dd på /dev/sda2 (f.eks.) i stedet for /dev/sda ved jeg
>> ikke om størrelsen følger med.
>
>
> [root@localhost mnt]# dd if=/dev/sda1 of=/dev/sda11
> 29977227+0 records in
> 29977227+0 records out
> 15348340224 bytes (15 GB) copied, 3372,5 s, 4,6 MB/s
>
>
> Og sda11 kan ikke læses. Så det dutter ikke.
>
> Hvad med tar -cj
>
Ja, man skal bruge tar til backup af en hel partition.

--
Med venlig hilsen

Jørgen Heesche
mailto:heesche@webspeed.dk

---

=?UTF-8?B?SsO4cmdlbiBIZWVzY2hl?= <heesche@webspeed.dk> writes:

>> Hvad med tar -cj
>>
>Ja, man skal bruge tar til backup af en hel partition.

Personligt vil jeg til enhver tid anbefale dump. Af sære
årsager har den været længe undervejs til ext2, men Debian
kender den i hvert fald:

dump - 4.4bsd dump and restore for ext2 filesystems

Fordelen ved dump er, at den er filsystem-centreret. Den har
ikke alle de ulemper, tar har, fordi tar er fil-centreret.


Hvis man alligevel vil bruge tar, så er her et par detaljer at
tænke over:

Udfordringen med tar er primært, at den ikke er mountpoint-
aware.

Tag dette eksempel:

$ df -h /usr /usr/local
Filesystem Size Used Avail Use% Mounted on
/dev/md1 5G 3G 2G 60% /usr
/dev/md2 145G 60G 79G 44% /usr/local

Hvis du tager en backup af /usr med tar, vil din tar-ball ikke
fylde 3 GB, sådan som du ønskede, men 63 GB. Den tager også
/usr/local med i købet.

Man skal derfor først sikre sig, at ens partition ikke har
andre partitions mounted "under" sig. Husk også at notere hvem
der ejer de mountpoints der ekskluderes. Hvis man i dette
eksempel ikke vil have /usr/local med, kan man jo...

# cd /usr
# tar jcvf /backup/usr.tar.bz2 bin doc include lib man sbin share

....altså tage alle directories pånær local med.

Men så får man slet ikke mountpointet local med! Derfor er det
vigtigt at notere sig mode og ejerskab af den:

$ ls -ld local
drwxrwsr-x 13 root staff 4096 Sep 13 2006 local

....så man ved, hvordan man skal oprette mountpointet igen.


Dernæst skal man huske på detaljer som sparse files, hvor tar
i mange udgaver må give op. GNU tar kan godt - man skal blot
huske at specifiere --sparse. Ellers kan ens backup pludselig
blive mange terabytes stor, selvom der reelt kun er 63 GB på
disken.

Endelig er der symlinks. Hvis man samtidig (som den oprindelige
var ude i) ændrer på opsætningen af maskinen, skal man tænke
på, om ens symlinks peger rigtigt efter ændringen.

Den sidste detalje her er også relevant for dump. Man kan måske
argumentere for, at tar faktisk har en styrke her: man kan ved
hjælp af --dereference på GNU tar vælge at lave backup af selve
filen. Det skal dog også gøres med omtanke; sædvanligvis er der
jo en grund til, at man har brugt symlinks.


Men igen: hvis man vil tage backup af en PARTITION, hvorfor så
bruge et FIL-centreret værktøj?

Mvh.
   Klaus.

---

Den Sat, 1 Dec 2007 10:44:57 +0000 (UTC) skrev Klaus Ellegaard:
> =?UTF-8?B?SsO4cmdlbiBIZWVzY2hl?= <heesche@webspeed.dk> writes:
>
>>> Hvad med tar -cj
>>>
>>Ja, man skal bruge tar til backup af en hel partition.
>
> Personligt vil jeg til enhver tid anbefale dump. Af sære
> årsager har den været længe undervejs til ext2, men Debian
> kender den i hvert fald:
>
> dump - 4.4bsd dump and restore for ext2 filesystems

Jeg mener bestemt også jeg har set den på Slackware for 10 år siden. Men
de fleste distro'er holdt op med at inkludere den, efter man fandt ud
af at hvis man læser fra den rå device, samtidig med at partitionen
er mountet, kan det f*cke buffer-cachen op, med risiko for at smadre
filsystemet. *Selvom der kun læses*.

> Hvis man alligevel vil bruge tar, så er her et par detaljer at
> tænke over:
>
> Udfordringen med tar er primært, at den ikke er mountpoint-
> aware.
>
> Tag dette eksempel:
>
> $ df -h /usr /usr/local
> Filesystem Size Used Avail Use% Mounted on
> /dev/md1 5G 3G 2G 60% /usr
> /dev/md2 145G 60G 79G 44% /usr/local
>
> Hvis du tager en backup af /usr med tar, vil din tar-ball ikke
> fylde 3 GB, sådan som du ønskede, men 63 GB. Den tager også
> /usr/local med i købet.

-l, --one-file-system
stay in local file system when creating an archive

Den kan begge dele, men som default tager den ikke hensyn til
hvad der ligger på hvilket filsystem. Når maskinen bryder sammen
og man må skifte den ud, er det jo ikke sikkert at man vælger
at partitionere den nye maskine på samme måde.

Hvordan har dump det med det? Hvis jeg tager backup med dump
af to 40 GB diske, og så skal restore det hele på en stor
160 GB?

> Dernæst skal man huske på detaljer som sparse files, hvor tar
> i mange udgaver må give op. GNU tar kan godt - man skal blot
> huske at specifiere --sparse. Ellers kan ens backup pludselig
> blive mange terabytes stor, selvom der reelt kun er 63 GB på
> disken.

Hvor mange sparse files har du?

Det er en cool feature, men jeg kan ikke mindes at have set den brugt
til noget fornuftigt. Det er dog en ret cool feature til at forvirre
folk der tror de ved en hel masse om *nix-systemer.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis <nospam@nospam.invalid> writes:

> -l, --one-file-system
> stay in local file system when creating an archive

Tak, så lærte jeg også lidt i dag

Meneh... det er så igen begrænset til GNU tar, og de øvrige
reservationer er stadig gældende.

>Hvordan har dump det med det? Hvis jeg tager backup med dump
>af to 40 GB diske, og så skal restore det hele på en stor
>160 GB?

Det er ikke noget problem. Fordelen ved dump er, at den er
designet til partition-backups (dvs. den beholder alle de -
mere eller mindre skjulte - features pr. fil, så en restore
er nøjagtig ens), men den kan også operere på filniveau.

Der er altså ikke noget krav om, at din restore skal ske til
en disk med samme specifikationer som den oprindelige. I det
konkrete tilfælde vil du have 120G fri på din nye disk efter
restore... og alle dine filer - almindelige, sparse, special,
whatever i god behold.

Netop dét er også grunden til, at jeg opponerer mod tar. Det
er et fint værktøj til at sende arkiver rundt med, men det er
ikke særlig velegnet til backup-formål, hvis meningen er at
man hurtigt skal kunne restore en hel partition. Man skal
simpelthen tænke for meget selv, og hvor der tænkes, er der
risiko for fejl.

Dump skal bare køres praktisk talt uden argumenter. Der er ikke
rigtig noget at tænke over og ingenting der kan gå galt.

>Hvor mange sparse files har du?

Nu har jeg en news-server af betragtelig størrelse, så dem
har jeg i omegnen af 35 GB (fysisk) af. Dem skal man ikke
lave en "almindelig" filbackup af. Den vil fylde adskillige
terabytes.

Man ved heller ikke, om der skulle dukke nogen op i anden
sammenhæng. Det er en hurtig og billig måde at lave en
"tabel" med fixed size cells.

>Det er en cool feature, men jeg kan ikke mindes at have set den brugt
>til noget fornuftigt. Det er dog en ret cool feature til at forvirre
>folk der tror de ved en hel masse om *nix-systemer.



Mvh.
   Klaus.

---

Den Sat, 1 Dec 2007 11:28:01 +0000 (UTC) skrev Klaus Ellegaard:
> Kent Friis <nospam@nospam.invalid> writes:
>
>> -l, --one-file-system
>> stay in local file system when creating an archive
>
> Tak, så lærte jeg også lidt i dag
>
> Meneh... det er så igen begrænset til GNU tar, og de øvrige
> reservationer er stadig gældende.

Har du checket manualen til andre tar-udgaver? Bare fordi den
har en "--" option, er det jo ikke sikkert den kun findes i
gnu-tar. Den har også en alm. kort option.

>>Hvordan har dump det med det? Hvis jeg tager backup med dump
>>af to 40 GB diske, og så skal restore det hele på en stor
>>160 GB?
>
> Det er ikke noget problem. Fordelen ved dump er, at den er
> designet til partition-backups (dvs. den beholder alle de -
> mere eller mindre skjulte - features pr. fil, så en restore
> er nøjagtig ens), men den kan også operere på filniveau.
>
> Der er altså ikke noget krav om, at din restore skal ske til
> en disk med samme specifikationer som den oprindelige. I det
> konkrete tilfælde vil du have 120G fri på din nye disk efter
> restore... og alle dine filer - almindelige, sparse, special,
> whatever i god behold.

Der skulle gerne kun være 80 GB fri, ellers læste du ikke hvad
jeg skrev.

>>Hvor mange sparse files har du?
>
> Nu har jeg en news-server af betragtelig størrelse, så dem
> har jeg i omegnen af 35 GB (fysisk) af. Dem skal man ikke
> lave en "almindelig" filbackup af. Den vil fylde adskillige
> terabytes.
>
> Man ved heller ikke, om der skulle dukke nogen op i anden
> sammenhæng. Det er en hurtig og billig måde at lave en
> "tabel" med fixed size cells.

Kun så længe "hullerne" er større end en blok. Lige så snart
du er oppe på at der lægger en record i hver blok, har du mistet
fordelen, også selvom der stadig er 99 frie records i hver blok.

Derfor er løsningen ikke specielt hensigtsmæssig, og de fleste
programmer bruger vel af samme grund en mere velvalgt metode.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis <nospam@nospam.invalid> writes:

>Har du checket manualen til andre tar-udgaver? Bare fordi den
>har en "--" option, er det jo ikke sikkert den kun findes i
>gnu-tar. Den har også en alm. kort option.

Solaris og HP-UX kan ikke. Jeg har ikke umiddelbart adgang til
andre Unices. (Well, jeg gider ikke checke min AMIX; den kan
med garanti ikke).

>Der skulle gerne kun være 80 GB fri, ellers læste du ikke hvad
>jeg skrev.

Du har ret; 80 GB tilbage. Det var to 40G diske. Det er stadig
ikke noget problem med dump.

>Kun så længe "hullerne" er større end en blok. Lige så snart
>du er oppe på at der lægger en record i hver blok, har du mistet
>fordelen, også selvom der stadig er 99 frie records i hver blok.

Det er korrekt. Men kan du komme på en anden løsning, der kan
implementeres i C på det samme antal linjer (2), og som har
samme performance?

Som alt andet i denne verden er det et spørgsmål om at opveje
fordele og ulemper. I news-tilfældet er konceptet vældig smart,
fordi det giver uovertruffen performance, intet behov for at
lave "vedligehold" på databasen, og man er garanteret mod at
løbe tør for inodes. Ulempen er, at man over tid kan få et
vældigt fragmenteret filsystem, hvilket - igen over tid - kan
give et problem med performance.

>Derfor er løsningen ikke specielt hensigtsmæssig, og de fleste
>programmer bruger vel af samme grund en mere velvalgt metode.

....i det omfang der findes sådan en.

Mvh.
   Klaus.

---

Den Sat, 1 Dec 2007 12:16:10 +0000 (UTC) skrev Klaus Ellegaard:
> Kent Friis <nospam@nospam.invalid> writes:
>
>>Har du checket manualen til andre tar-udgaver? Bare fordi den
>>har en "--" option, er det jo ikke sikkert den kun findes i
>>gnu-tar. Den har også en alm. kort option.
>
> Solaris og HP-UX kan ikke. Jeg har ikke umiddelbart adgang til
> andre Unices. (Well, jeg gider ikke checke min AMIX; den kan
> med garanti ikke).
>
>>Der skulle gerne kun være 80 GB fri, ellers læste du ikke hvad
>>jeg skrev.
>
> Du har ret; 80 GB tilbage. Det var to 40G diske. Det er stadig
> ikke noget problem med dump.

Ok. Så er dump mere avanceret end jeg havde forventet.

Kan den så også restore på en anden type filsystem?

>>Kun så længe "hullerne" er større end en blok. Lige så snart
>>du er oppe på at der lægger en record i hver blok, har du mistet
>>fordelen, også selvom der stadig er 99 frie records i hver blok.
>
> Det er korrekt. Men kan du komme på en anden løsning, der kan
> implementeres i C på det samme antal linjer (2), og som har
> samme performance?

Hvis det endelig skal være, så kan samme algoritme bruges uden
sparse files, med samme performance, og når du når op på en
record per blok, vil de også have samme pladsforbrug.

> Som alt andet i denne verden er det et spørgsmål om at opveje
> fordele og ulemper. I news-tilfældet er konceptet vældig smart,
> fordi det giver uovertruffen performance, intet behov for at
> lave "vedligehold" på databasen, og man er garanteret mod at
> løbe tør for inodes. Ulempen er, at man over tid kan få et
> vældigt fragmenteret filsystem, hvilket - igen over tid - kan
> give et problem med performance.
>
>>Derfor er løsningen ikke specielt hensigtsmæssig, og de fleste
>>programmer bruger vel af samme grund en mere velvalgt metode.
>
> ...i det omfang der findes sådan en.

Prøv at spørge MySQL, Oracle, Informix, osv. folkene om der findes
en

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis <nospam@nospam.invalid> writes:

>Ok. Så er dump mere avanceret end jeg havde forventet.

>Kan den så også restore på en anden type filsystem?

Jeg har ikke prøvet, men det vil jeg tro.

>> ...i det omfang der findes sådan en.

>Prøv at spørge MySQL, Oracle, Informix, osv. folkene om der findes
>en

Det er jo igen et spørgsmål om at afveje fordele og ulemper.
Lad os sige, at du har en vældig travl news-server, der har
200 TB artikler og skal håndtere at levere 1.000 svar pr.
sekund.

Hvad er hurtigst og skalerer bedst:

(1) at en frontend laver et opslag i et read-only btree for
at finde artiklens lokation og herefter laver en fseek og
en fread direkte til artiklen på SAN'et og leverer artiklen,

eller

(2) at frontenden brygger et SQL-statement sammen, sender
det til en database-server via netværket, der processerer
statementet, slår artiklen op, sender det tilbage via nettet
til frontenden, der så kan sende det tilbage som svar?

Jeg gætter på, at (2) er en faktor 10-100 langsommere og i
øvrigt vil koste mange millioner kroner i licens til Oracle.
Desuden skalerer den slet ikke. Hvor stor en database-server
skal du have for at håndtere det 10-dobbelte load?

Mvh.
   Klaus.

---

Den Sat, 1 Dec 2007 13:01:51 +0000 (UTC) skrev Klaus Ellegaard:
> Kent Friis <nospam@nospam.invalid> writes:
>
>>> ...i det omfang der findes sådan en.
>
>>Prøv at spørge MySQL, Oracle, Informix, osv. folkene om der findes
>>en
>
> Det er jo igen et spørgsmål om at afveje fordele og ulemper.
> Lad os sige, at du har en vældig travl news-server, der har
> 200 TB artikler og skal håndtere at levere 1.000 svar pr.
> sekund.
>
> Hvad er hurtigst og skalerer bedst:
>
> (1) at en frontend laver et opslag i et read-only btree for
> at finde artiklens lokation og herefter laver en fseek og
> en fread direkte til artiklen på SAN'et og leverer artiklen,

"read-only btree"? Hvordan fungerer det hvis nye artikler ikke
skal skrives deri?

> eller
>
> (2) at frontenden brygger et SQL-statement sammen, sender
> det til en database-server via netværket, der processerer
> statementet, slår artiklen op, sender det tilbage via nettet
> til frontenden, der så kan sende det tilbage som svar?
>
> Jeg gætter på, at (2) er en faktor 10-100 langsommere

At tage bilen til Århus er også 10-100 gange langsommere end at gå,
hvis du insisterer på at den skal være parkeret i en garage i
Hong Kong, og sejles hertil med sejlbåd.

> og i
> øvrigt vil koste mange millioner kroner i licens til Oracle.

Hvilket patent har Oracle på datastrukturer der er egnede til
en database?

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis <nospam@nospam.invalid> writes:

>"read-only btree"? Hvordan fungerer det hvis nye artikler ikke
>skal skrives deri?

Ideen er, at man har en writer og en række readers. Writeren
opdaterer træet, readerne læser fra det.

Mvh.
   Klaus.

---

Den Sat, 1 Dec 2007 17:17:52 +0000 (UTC) skrev Klaus Ellegaard:
> Kent Friis <nospam@nospam.invalid> writes:
>
>>"read-only btree"? Hvordan fungerer det hvis nye artikler ikke
>>skal skrives deri?
>
> Ideen er, at man har en writer og en række readers. Writeren
> opdaterer træet, readerne læser fra det.

Altså et ganske alm. index der fortæller hvor tingene ligger. Det
kan præcis lige så godt pege på records der ligger efter hinanden,
som det kan pege på records der ligger med hundredevis af megabytes
imellem.

Det er så godt nok variabel størrelse records, men til gengæld må
man forvente at de expire'r i rækkefølge, så fragmentering burde
der heller ikke være det store problem med.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis <nospam@nospam.invalid> writes:

>Det er så godt nok variabel størrelse records, men til gengæld må
>man forvente at de expire'r i rækkefølge, så fragmentering burde
>der heller ikke være det store problem med.

Bufferne er cykliske. Så når en buffer "vender rundt", er det
ikke sikkert, der er plads til en artikel samme sted, som den
der lå der i sidste cycle.

Mvh.
   Klaus.

---

Den Sat, 1 Dec 2007 17:49:33 +0000 (UTC) skrev Klaus Ellegaard:
> Kent Friis <nospam@nospam.invalid> writes:
>
>>Det er så godt nok variabel størrelse records, men til gengæld må
>>man forvente at de expire'r i rækkefølge, så fragmentering burde
>>der heller ikke være det store problem med.
>
> Bufferne er cykliske. Så når en buffer "vender rundt", er det
> ikke sikkert, der er plads til en artikel samme sted, som den
> der lå der i sidste cycle.

En cyklisk buffer er da netop kendetegnet ved at det fylder op fra
en ende af, og tømmes fra en ende af. Den frie plads vil dermed
ligge samlet.

Og selv hvis den ikke gør, er usenet-artikler (undtagen binaries)
typisk små, så at der ikke er plads til en artikel, men der er
plads til at lave frie blokke a 4k (ved default indstillinger) er
ikke noget der vil ske så tit at der er den store besparelse ved det.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Klaus Ellegaard wrote:

> Men igen: hvis man vil tage backup af en PARTITION, hvorfor så
> bruge et FIL-centreret værktøj?

Fordi den nøjagtige størelse på partionerne kender jeg ikke.
Partitions tabellen er ødelagt.

Hvordan vil du forslå mig, at komme videre derfra?
Som jeg ser det, så er det sikkerste, at tage en backup af det jeg vil
gemme, og så lade mandrivas diskpartitions værktøj slette partitionerne, og
oprette dem på ny, og så restore backup, og så er jeg kørende igen.

Eller hvad vil du forslå?
Jeg tør ikke begynde at rode med partitions tabellen, uden at have en backup
først. Når jeg køre drakdisk siger den:

,----[ ]
| Jeg kan ikke læse partitionstabellen for enhed sda, den er for ødelagt for
mig :( Jeg kan forsøge fortsat at udblanke dårlige partitioner (ALLE DATA
vil gå tabt!). Den anden mulighed er at forbyde DrakX at ændre
partitionstabellen. (fejlen er extended partition: more than one extended
partition.
| )
|
| Er du indforstået med at ødelægge alle partitionerne?
`----

--
Med venlig hilsen

Ivar Madsen

---

Ivar Madsen <spam.news@milli.dk> writes:

>Fordi den nøjagtige størelse på partionerne kender jeg ikke.
>Partitions tabellen er ødelagt.

Hvad siger en "fdisk -l /dev/sda"? (Jeg kalder den sda, erstat
på passende vis).

Den burde skrive noget à la...

# fdisk -l /dev/sda

Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 1 3 24066 83 Linux
/dev/sda2 4 768 6144862+ 83 Linux
/dev/sda3 769 801 265072+ 82 Linux swap / Solaris

Hvis du kan komme så langt, er den ikke ligefrem ødelagt. Forudsat
at de data er korrekte. Du siger, du kan læse partitionen, så den
må have det nogenlunde godt.

Mit indlæg til Jørgen var primært omkring konceptet med, at man
generelt skal anvende det rigtige værktøj til den rigtige opgave.
Og til backup af en partition er et partition-centreret værktøj
det rette. Her er vi imidlertid interesseret i at redde filer,
og så er tar naturligvis det rette.

Som jeg skrev, er tar ligeglad med partitioner (som udgangspunkt).
Det vil sige, at hvis du går ned i / og laver en tar derfra, får
du revl og krat med. Fra alle dine diske.

Jeg ville tage én klump ad gangen, for så er det meget nemmere at
omorganisere verden bagefter. Hvis det er din roddisk, der er i
stykker, så lav en ls:

# cd / ; ls
bin dev etc lib lost+found mnt proc sbin sys usr
boot emul home lib64 media opt root srv tmp var

Umiddelbart kan vi afskrive lost+found, media, proc, sys og tmp.
Der er ikke noget i dem, vi skal have backup af. Resten er vi
derimod interesseret i (medmindre nogle af dem er mounted på
diske, der har det godt).

Så hvad med:

# cd /
# for a in bin boot dev emul etc home lib lib64 mnt ....... var
> do
> echo Laver backup af $a
> tar jcf /anden-disk/${a}.tar.bz2 $a
> done

Voila! Så har du på /anden-disk en bin.tar.bz2, boot.tar.bz2, ...
...., var.tar.bz2

Måske skal du droppe mnt hvis alle dine diske er mounted dér.
Er der syge diske iblandt dem, kan du også køre en:

# cd /mnt
# ls
cdrom floppy sda2 sda3 hdc2 sdd3
# for a in sda2 sda3 (altså liste de kataloger du ønsker backup af)
> do
> echo Laver backup af $a
> tar jcf /anden-disk/${a}.tar.bz2 $a
> done

Så skulle du være der, hvor du i hvert fald har hele sda med i
din backup. Men check nu lige, at det stemmer.

Hvis en af dine backups bliver usandsynligt store (får disken
til at løbe fuld), har du sikkert sparse files med. Ret tar-
linjen til "tar jcSf ...."

Fordelen ved denne metode er, at du nu har delt dine data op i
logiske bidder. Du kan restore /anden-disk/boot.tar.bz2 til din
nye boot partition. Du kan lave en separat /home og restore
/anden-disk/home.tar.bz2 til den. Og så videre.

Eller du kan lave det omvendte: i stedet for at have mange små
partitions, kan du lave én stor og bare restore alle filerne
til den ene. Med /boot som mulig undtagelse

>Jeg tør ikke begynde at rode med partitions tabellen, uden at have en backup
>først. Når jeg køre drakdisk siger den:

Det lyder altså skummelt. Jeg kunne godt tænke mig at se det output
af fdisk.

Som udgangspunkt tror jeg ikke, der er noget galt med dine partitions
så data er næppe ramt. Det er bare MBR'en, der har det skidt. Hvordan
den kan have det skidt og samtidig være læsbar, er lidt skummelt.

Jeg tror, det er drakdisk, der ikke har helt styr på andet end den
perfekte situation.

Men stadig: hvem har lyst til at satse på at køre fra en syg disk,
som måske først om et par måneder begynder at vise tegn på sygdom?

Mvh.
   Klaus.

PS! Husk nu den backup for fremtiden

---

Klaus Ellegaard wrote:

>>Jeg tør ikke begynde at rode med partitions tabellen, uden at have en
>>backup først. Når jeg køre drakdisk  siger den:
>
> Det lyder altså skummelt. Jeg kunne godt tænke mig at se det output
> af fdisk.
>
> Som udgangspunkt tror jeg ikke, der er noget galt med dine partitions
> så data er næppe ramt. Det er bare MBR'en, der har det skidt. Hvordan
> den kan have det skidt og samtidig være læsbar, er lidt skummelt.
>
> Jeg tror, det er drakdisk, der ikke har helt styr på andet end den
> perfekte situation.
>
> Men stadig: hvem har lyst til at satse på at køre fra en syg disk,
> som måske først om et par måneder begynder at vise tegn på sygdom?

# fdisk -l /dev/sda
Advarsel: ekstra lænkepeger (link pointer) i partitionstabel 10

Disk /dev/sda: 164.6 Gb, 164695473664 byte
255 heads, 63 sectors/track, 20023 cylinders
Units = cylindre of 16065 * 512 = 8225280 bytes
Disk identifier: 0xc931c931

Enhed Opstart Start Slut Blokke Id System
/dev/sda1 * 1 1866 14988613+ 83 Linux
/dev/sda2 1867 20023 145846102+ 5 Udvidet
/dev/sda5 1867 5699 30788541 83 Linux
/dev/sda6 5700 7604 15301881 83 Linux
/dev/sda7 7605 11205 28925001 83 Linux
/dev/sda8 11206 11714 4088511 83 Linux
/dev/sda9 11715 16634 39519868+ 83 Linux
/dev/sda10 16635 17091 3670821 82 Linux swap / Solaris
/dev/sda11 17092 20023 23551258+ 83 Linux

Men jeg har fundet ud af at den install jeg lavede for at kunne boote
maskine igen, virker meget beder, end den på den gamle, som jeg ville rede.
Eneste forskæld jeg har gjort under install, er at jeg valgte både at
installere kde, og gnome.
Nu kan den godt køre sådan noget som google-earth, og Compiz Fusion, det
kunne jeg ikke før. Så jeg har overført /home og så forsætter jeg med den
nye install. Så må jeg bare installere de programmer på ny, som jeg nu
mangler, og så tage opsætningen fra /~ og /etc, og kopiere dem over.

Det giver mig noget arbejde, men på dan anden side, så spare det mig også
for noget arbejde, og jeg har nu fået nået jeg ikke kunne finde ud af at få
til at virke før,,,

Nu kunne jeg jo så godt finde på at lege lidt med min sda, for at få rettet
fejlen, som win XP Home installer lavede.


--
Mvh

Ivar

---

Ivar Madsen <news.cybercity.dk@milli.dk> writes:

># fdisk -l /dev/sda
>Advarsel: ekstra lænkepeger (link pointer) i partitionstabel 10

Det tørrer nok. Men jeg vil nok stadig lave en reinstallation
for en god ordens skyld.

Det er lidt voldsomt at have 11 partitions. Hvis det bare
er en kværn til hjemmebrug, hvorfor så ikke nøjes med tre:

1) /boot
2) /
3) swap

Andre diske kan du mounte under /mnt og proppe dem ind i
filsystemet på passende steder.

For eksempel kan du have din /dev/sdb1 mounted som /mnt/sdb1
og et symlink fra /home/ivar/software til /mnt/sdb1/software

Det giver dig den fordel, at du ikke har 1 GB i /dev/sda2,
3 GB i /dev/sda3, 2 GB i /dev/sda4, osv. som ikke umiddelbart
kan bruges til noget, fordi filerne så kommer til at ligge
tossede steder.

Det kan hurtigt blive 10-20 GB, som du reelt har "spildt".

Hvis du endelig skal have så mange, kan du overveje at køre
med LVM. Den giver dig mulighed for at tildele ekstra plads
til hver enkelt volume, efterhånden som de løber fuld. På
den måde slipper du for at allokere en masse "spildplads".

>Nu kan den godt køre sådan noget som google-earth, og Compiz Fusion, det
>kunne jeg ikke før. Så jeg har overført /home og så forsætter jeg med den
>nye install. Så må jeg bare installere de programmer på ny, som jeg nu
>mangler, og så tage opsætningen fra /~ og /etc, og kopiere dem over.

God plan. But still... en defekt partition table skal nok fikses
inden du erklærer maskinen for stabil. Udover lidt hobbybrug har
jeg ikke så meget med x86-maskiner at gøre, så jeg kan ikke præcist
vurdere hvor galt det evt. kan gå.

Men personligt kan jeg slet ikke lide, at der er den mindste smule
bøvl med diske. De er trods alt ret kritiske for mine data.

>Nu kunne jeg jo så godt finde på at lege lidt med min sda, for at få rettet
>fejlen, som win XP Home installer lavede.

Held og lykke

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:

>># fdisk -l /dev/sda
>>Advarsel: ekstra lænkepeger (link pointer) i partitionstabel 10
> Det tørrer nok. Men jeg vil nok stadig lave en reinstallation
> for en god ordens skyld.
>
> Det er lidt voldsomt at have 11 partitions. Hvis det bare
> er en kværn til hjemmebrug, hvorfor så ikke nøjes med tre:
>
> 1) /boot
> 2) /
> 3) swap

Faktisk så har jeg kun haft.

/
/home
/swap
mnt/windows
/[gamle systemer, som ikke er slettet.]

Det er derfor jeg skrev i det oprentlige indlæg, at der er to partitioner,
hvor jeg vil have det hele, og enkelte filer på resten, som derefter bare
skal slagtes.


>>Nu kan den godt køre sådan noget som google-earth, og Compiz Fusion, det
>>kunne jeg ikke før. Så jeg har overført /home og så forsætter jeg med den
>>nye install. Så må jeg bare installere de programmer på ny, som jeg nu
>>mangler, og så tage opsætningen fra /~ og /etc, og kopiere dem over.
>
> God plan. But still... en defekt partition table skal nok fikses
> inden du erklærer maskinen for stabil. Udover lidt hobbybrug har
> jeg ikke så meget med x86-maskiner at gøre, så jeg kan ikke præcist
> vurdere hvor galt det evt. kan gå.
>
> Men personligt kan jeg slet ikke lide, at der er den mindste smule
> bøvl med diske. De er trods alt ret kritiske for mine data.

Enig, her ved jeg dog med 100 % sikkerhed, at det er windows installer, som
har lavet rod i den, og ikke som disken er syg, så derfor er jeg ikke det
mindeste bekømerede for at lade drakdisk slette partitionerne, og så bruge
disken igen.


--
Mvh

Ivar