---

Jeg har sat en ny harddisk i min server der kører Fedora Core 1.
Hvordan formaterer jeg og monterer den?
Er der noget med at det er smart at have swap på en anden disk end den
der bootes på og som systemet ligger på?
Hvordan ændres det?

--
med venlig hilsen
Leonard - http://leonard.dk/

---

Leonard wrote:

> Er der noget med at det er smart at have swap på en anden disk end den
> der bootes på og som systemet ligger på?

Der kan kun læses / skrives på disken af en ting af gangen, så hvis du har
brug for væsentligt mere RAM end du har, og der skal swappes, så vil der
kunne læses / skrives på disken, på samme tid som der swappes.

--
Med venlig hilsen

Ivar Madsen

---

Leonard wrote:
>
> Jeg har sat en ny harddisk i min server der kører Fedora Core 1.
> Hvordan formaterer jeg og monterer den?

Du skal partitionere den og lave et filsystem. En egentlig
formatering er ikke nødvendig. Jeg plejer at bruge fdisk
til at partitionere disken. Til at lave filsystemet vil
mkfs.ext3 nok være at foretrække. Pas på hvad du gør, det
kræver kun en forkert kommando at forårsage uoprettelig
datatab. Og overvej din partitionering grundigt på
forhånd, det er så svært at ændre når først disken er
fyldt med data.

> Er der noget med at det er smart at have swap på en anden disk end den
> der bootes på og som systemet ligger på?

Du kan opnå bedre performance ved at fordele belastningen
jævnt over flere diske. Hvis system partitionen og swap
partitionen er de mest brugte kan det give bedre performance
at have dem på hver sin disk. Hvis du bruger IDE diske bør
du sørge for at de sidder på hver sit kabel.

> Hvordan ændres det?

Du laver enten en swap partition eller en swap fil på den
nye disk. En swap partition giver så vidt jeg ved lidt
bedre performance, jeg ved ikke hvor stor forskel det gør.
Dernæst kan du ændre i /etc/fstab for at tilføje en swap
partition/fil mere. Du kan så sætte prioriteterne så den
nye bruges først.

--
Kasper Dupont

---

Kasper Dupont <kasperd@daimi.au.dk> wrote:

>Du skal partitionere den og lave et filsystem. En egentlig
>formatering er ikke nødvendig. Jeg plejer at bruge fdisk
>til at partitionere disken. Til at lave filsystemet vil
>mkfs.ext3 nok være at foretrække. Pas på hvad du gør, det
>kræver kun en forkert kommando at forårsage uoprettelig
>datatab. Og overvej din partitionering grundigt på
>forhånd, det er så svært at ændre når først disken er
>fyldt med data.

At lave et filsystem er vel det samme som at formattere?

Det er mest det med at passe på datatab jeg er bange for, der sidder
nu 2 diske i maskinen, den ene er systemet og de data jeg har på og
den anden er den nye.

Er fdisk det samme som til DOS/WIN?
- er det bare at skrive fdisk og så kommer der noget at vælge imellem?

Jeg skal bruge disken til film, musik, billeder og backup (store
zipfiler fran en anden maskine) og disken er på 300 GB. Jeg vil helst
ikke dele den i mange dele, da det typisk er store filer, som vil give
stor spildplads, men er der problemer i at have så stor en disk?

Jeg går udfra at disken kommer til at hedde hdb og så opretter jeg vel
filsystem ved at skrive
mkfs.ext3 /dev/hdb


--
med venlig hilsen
Leonard - http://leonard.dk/

---

Leonard wrote:
>
> At lave et filsystem er vel det samme som at formattere?

At formatere plejer at betyde at man fysisk overskriver
hver eneste sektor på disken. Men det er ikke nødvendigt,
mkfs.ext3 skriver bare de nødvendige metadata, hvilket er
langt hurtigere.

>
> Det er mest det med at passe på datatab jeg er bange for, der sidder
> nu 2 diske i maskinen, den ene er systemet og de data jeg har på og
> den anden er den nye.
>
> Er fdisk det samme som til DOS/WIN?

Nej, ikke helt.

> - er det bare at skrive fdisk og så kommer der noget at vælge imellem?

Du skal skrive navnet på disken efter fdisk. Hvis den
nye disk f.eks. hedder hdc skriver du:
fdisk /dev/hdc

Hvis du skriver "grep hd /var/log/dmesg" burde du se
hvilke diske og partitioner kernen har fundet ved
opstart, så burde du kunne finde ud af, hvilken, der
er den nye.

Det er under antagelse af at det er IDE diske, men det
må det vel være med den størrelse.

>
> Jeg skal bruge disken til film, musik, billeder og backup (store
> zipfiler fran en anden maskine) og disken er på 300 GB. Jeg vil helst
> ikke dele den i mange dele, da det typisk er store filer, som vil give
> stor spildplads, men er der problemer i at have så stor en disk?

Jeg kører selv med et 289GB ext3 filsystem under FC1,
og det har ikke givet mig nogen problemer. Et stort
filsystem er kun et problem hvis der opstår nogle
inkonsistenser, som fsck ikke lige kan håndtere,
eller hvis du finder ud af, at du hellere vil køre med
et andet filsystem.

For et par år siden rendte jeg ind i et problem med et
reiserfs filsystem, som kun blev værre af at bruge
fsck. Derefter holdt jeg op med at bruge reiserfs.

>
> Jeg går udfra at disken kommer til at hedde hdb og så opretter jeg vel
> filsystem ved at skrive
> mkfs.ext3 /dev/hdb

Hvis den nye disk hedder hdb, så er det fordi den er
sat på samme kabel som hda. Det er skidt for performance,
og vil betyde at hvis der opstår et problem med den ene
disk, så kan du måske ikke kommunikere med den anden.
Jeg kører helst aldrig med mere end en enhed pr. IDE
kabel.

Desuden er det nok ikke en god idé at lægge sit filsytem
direkte på /dev/hdb (eller hdc). Du bør i stedet
oprette en partition (eller flere) og så køre mkfs på
partitionen. Lav evt. en swap partition og brug resten
til en data partition. Bemærk at en swap partition kan
højst være på 2GB.

--
Kasper Dupont

---

Kasper Dupont <kasperd@daimi.au.dk> wrote:

>Hvis du skriver "grep hd /var/log/dmesg" burde du se
>hvilke diske og partitioner kernen har fundet ved
>opstart, så burde du kunne finde ud af, hvilken, der
>er den nye.

Og der kommer der noget med hda og hdc, og nogle fejl på hdc, så det
passer jo fintmed at hdc er den nye.

Men fdisk /dev/hdc giver også Kunne ikke åbne /dev/hdc
fdisk /dev/hda fortæller mig noget om disken og jeg har så afsluttet
med det samme med Ctrl-C

Hvad gør jeg så ved den?

--
med venlig hilsen
Leonard - http://leonard.dk/

---

Leonard <nospam@invalid.invalid> writes:

> Kasper Dupont <kasperd@daimi.au.dk> wrote:
>
> >Hvis du skriver "grep hd /var/log/dmesg" burde du se
> >hvilke diske og partitioner kernen har fundet ved
> >opstart, så burde du kunne finde ud af, hvilken, der
> >er den nye.
>
> Og der kommer der noget med hda og hdc, og nogle fejl på hdc, så det
> passer jo fintmed at hdc er den nye.
>
> Men fdisk /dev/hdc giver også Kunne ikke åbne /dev/hdc
> fdisk /dev/hda fortæller mig noget om disken og jeg har så afsluttet
> med det samme med Ctrl-C
>
> Hvad gør jeg så ved den?

Hmm. Du må vist hellere fortælle os hvad der stod i de
fejlmeddelelser. Helst ikke bare output fra grep, for der kunne stå
noget i linjer der ikke indeholder "hd". Læs /var/log/dmesg med "more"
eller "less" og klip og klistr til mailen.

--
O__ ---- Peter Dalgaard Blegdamsvej 3
c/ /'_ --- Dept. of Biostatistics 2200 Cph. N
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907

---

Peter Dalgaard <p.dalgaard@biostat.ku.dk> wrote:

>Hmm. Du må vist hellere fortælle os hvad der stod i de
>fejlmeddelelser.

ICH4: chipset revision 1
ICH4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
hda: ST380011A, ATA DISK drive
blk: queue c040cfc0, I/O limit 4095Mb (mask 0xffffffff)
hdc: Maxtor 5A300J0, ATA DISK drive
blk: queue c040d41c, I/O limit 4095Mb (mask 0xffffffff)
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: attached ide-disk driver.
hda: host protected area => 1
hda: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=9729/255/63,
UDMA(100)
Partition check:
hda: hda1 hda2 hda3
hdc:end_request: I/O error, dev 16:00 (hdc), sector 0
end_request: I/O error, dev 16:00 (hdc), sector 2
end_request: I/O error, dev 16:00 (hdc), sector 4
end_request: I/O error, dev 16:00 (hdc), sector 6
end_request: I/O error, dev 16:00 (hdc), sector 0
end_request: I/O error, dev 16:00 (hdc), sector 2
end_request: I/O error, dev 16:00 (hdc), sector 4
end_request: I/O error, dev 16:00 (hdc), sector 6
unable to read partition table
ide: late registration of driver.
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27


--
med venlig hilsen
Leonard - http://leonard.dk/

---

Den Sun, 14 Nov 2004 19:38:49 +0100 skrev Leonard:
> Peter Dalgaard <p.dalgaard@biostat.ku.dk> wrote:
>
>>Hmm. Du må vist hellere fortælle os hvad der stod i de
>>fejlmeddelelser.
>
> hdc:end_request: I/O error, dev 16:00 (hdc), sector 0
> end_request: I/O error, dev 16:00 (hdc), sector 2
> end_request: I/O error, dev 16:00 (hdc), sector 4
> end_request: I/O error, dev 16:00 (hdc), sector 6
> end_request: I/O error, dev 16:00 (hdc), sector 0
> end_request: I/O error, dev 16:00 (hdc), sector 2
> end_request: I/O error, dev 16:00 (hdc), sector 4
> end_request: I/O error, dev 16:00 (hdc), sector 6
> unable to read partition table

Check at kablerne (især IDE-kablet) sidder rigtigt i - i begge ender.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

Kent Friis <nospam@nospam.invalid> writes:

> Den Sun, 14 Nov 2004 19:38:49 +0100 skrev Leonard:
> > Peter Dalgaard <p.dalgaard@biostat.ku.dk> wrote:
> >
> >>Hmm. Du må vist hellere fortælle os hvad der stod i de
> >>fejlmeddelelser.
> >
....
> > end_request: I/O error, dev 16:00 (hdc), sector 6
> > unable to read partition table
>
> Check at kablerne (især IDE-kablet) sidder rigtigt i - i begge ender.

Nemlig. Ellers er jeg alvorligt bange for at disken er meget meget
syg.

--
O__ ---- Peter Dalgaard Blegdamsvej 3
c/ /'_ --- Dept. of Biostatistics 2200 Cph. N
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907

---

Peter Dalgaard <p.dalgaard@biostat.ku.dk> wrote:

>> Check at kablerne (især IDE-kablet) sidder rigtigt i - i begge ender.

Nu har jeg skiftet IDE-kablet.
Og bootet med en gammel win98-diskette, og der kan jeg godt køre fdisk
og partitionere harddisken (selvfølgelig har jeg kun forsøgt på den
nye).
Desværre har det ikke ændret noget når jeg booter op i Fedora igen ...

>Nemlig. Ellers er jeg alvorligt bange for at disken er meget meget
>syg.

Jamen, når disken kan findes i bios og i DOS?

--
med venlig hilsen
Leonard - http://leonard.dk/

---

Leonard <nospam@invalid.invalid> writes:

> Peter Dalgaard <p.dalgaard@biostat.ku.dk> wrote:
>
> >> Check at kablerne (især IDE-kablet) sidder rigtigt i - i begge ender.
[Det var nu Kent..]

> Nu har jeg skiftet IDE-kablet.
> Og bootet med en gammel win98-diskette, og der kan jeg godt køre fdisk
> og partitionere harddisken (selvfølgelig har jeg kun forsøgt på den
> nye).
> Desværre har det ikke ændret noget når jeg booter op i Fedora igen ...
>
> >Nemlig. Ellers er jeg alvorligt bange for at disken er meget meget
> >syg.
>
> Jamen, når disken kan findes i bios og i DOS?

Tja så er den diagnose jo nok ikke helt rigtig... Er det den eneste
disk på controlleren? Er den anden disk jumpered korrekt?

Og forresten, Google fandt en fyr der fik præcis dit problem fordi
hans boot linje havde hdc=ide-scsi...

--
O__ ---- Peter Dalgaard Blegdamsvej 3
c/ /'_ --- Dept. of Biostatistics 2200 Cph. N
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907

---

Peter Dalgaard wrote:
>
> Google fandt en fyr der fik præcis dit problem fordi
> hans boot linje havde hdc=ide-scsi...

Jeg har på fornemmelsen at det her problem kan skyldes
noget lignende. (Det var derfor jeg bad om at se hvilke
parametre kernen blev startet med).

--
Kasper Dupont

---

Leonard wrote:
>
> Peter Dalgaard <p.dalgaard@biostat.ku.dk> wrote:
>
> >Hmm. Du må vist hellere fortælle os hvad der stod i de
> >fejlmeddelelser.
>
> ICH4: chipset revision 1
> ICH4: not 100% native mode: will probe irqs later
> ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
> ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
> hda: ST380011A, ATA DISK drive
> blk: queue c040cfc0, I/O limit 4095Mb (mask 0xffffffff)
> hdc: Maxtor 5A300J0, ATA DISK drive
> blk: queue c040d41c, I/O limit 4095Mb (mask 0xffffffff)
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> hda: attached ide-disk driver.
> hda: host protected area => 1
> hda: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=9729/255/63,
> UDMA(100)

Her er noget galt. Den burde udskrive oplysninger om
geometri af hdc på dette sted. Hvilke parametre har
du givet til kernen? Og er du sikker på at controlleren
virker med diske på ovre 128GB?

> Partition check:
> hda: hda1 hda2 hda3
> hdc:end_request: I/O error, dev 16:00 (hdc), sector 0
> end_request: I/O error, dev 16:00 (hdc), sector 2
> end_request: I/O error, dev 16:00 (hdc), sector 4
> end_request: I/O error, dev 16:00 (hdc), sector 6
> end_request: I/O error, dev 16:00 (hdc), sector 0
> end_request: I/O error, dev 16:00 (hdc), sector 2
> end_request: I/O error, dev 16:00 (hdc), sector 4
> end_request: I/O error, dev 16:00 (hdc), sector 6
> unable to read partition table
> ide: late registration of driver.
> md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
>
> --
> med venlig hilsen
> Leonard - http://leonard.dk/

--
Kasper Dupont

---

Kasper Dupont <kasperd@daimi.au.dk> wrote:

>Her er noget galt. Den burde udskrive oplysninger om
>geometri af hdc på dette sted. Hvilke parametre har
>du givet til kernen? Og er du sikker på at controlleren
>virker med diske på ovre 128GB?

Aner det ikke, jeg har ikke givet kernen nogle parametre, bare
installeret den.
Controlleren er onboard og bundkortet er et nyere Intel med en 2GHz
processor, så mon ikke det kan klare en stor disk?


--
med venlig hilsen
Leonard - http://leonard.dk/

---

Leonard wrote:
>
> Aner det ikke, jeg har ikke givet kernen nogle parametre, bare
> installeret den.

Check lige /proc/cmdline

> Controlleren er onboard og bundkortet er et nyere Intel med en 2GHz
> processor, så mon ikke det kan klare en stor disk?

Det burde den nok kunne klare. Jeg er også
mest tilbøjelig til at tro, at kernen får en
eller anden forkert parameter ved opstart.

--
Kasper Dupont

---

Kasper Dupont <kasperd@daimi.au.dk> wrote:

>Check lige /proc/cmdline

Den er tom.

--
med venlig hilsen
Leonard - http://leonard.dk/

---

Leonard wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> wrote:
>
> >Check lige /proc/cmdline
>
> Den er tom.

Det kan vist ikke lade sig gøre. Prøv lige at bruge cat.

--
Kasper Dupont

---

Kasper Dupont <kasperd@daimi.au.dk> wrote:

>> >Check lige /proc/cmdline
>>
>> Den er tom.
>
>Det kan vist ikke lade sig gøre. Prøv lige at bruge cat.

Ja, så kommer der en linie frem:

ro root=LABEL=/ hdc=ide-scsi rhgb

Men når jeg kigger på /proc/ i Filhåndtering står der:

cmdline 0 B Tomt dokument

og åbner jeg cmdline i KWrite er den også bare tom, så nu du fortæller
mig at jeg skal rette cmdline, så må du også meget gerne fortælle mig
hvordan jeg gør.

Jeg har en anden ældre PC stående med en HD magen til i, og dens
cmdline er fuldstændig magen til, men der sidder disken også som hdb,
altså på samme controller som systemdisken. (Hvilket så ikke er
optimalt, så det laver jeg måske om på en dag jeg har tid, og fået det
til at virke i den PC jeg har problemer med nu.)

--
med venlig hilsen
Leonard - http://leonard.dk/

---

Leonard wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> wrote:
>
> >> >Check lige /proc/cmdline
> >>
> >> Den er tom.
> >
> >Det kan vist ikke lade sig gøre. Prøv lige at bruge cat.
>
> Ja, så kommer der en linie frem:
>
> ro root=LABEL=/ hdc=ide-scsi rhgb

OK, og som vi allerede havde mistanke om står der en
hdc=ide-scsi option der. Den option kan bruges til
ATAPI enheder, men du ikke er ikke interesseret i at
bruge den til din harddisk. Så den option skal vi
have væk.

>
> Men når jeg kigger på /proc/ i Filhåndtering står der:
>
> cmdline 0 B Tomt dokument
>
> og åbner jeg cmdline i KWrite er den også bare tom, så nu du fortæller
> mig at jeg skal rette cmdline, så må du også meget gerne fortælle mig
> hvordan jeg gør.

/proc/cmdline er slet ikke en fil, og du kan ikke
ændre på den. I stedet skal du ændre på konfigurationen
af din bootloader. Du bruger sikkert grub (ellers må
du fortælle os hvilken loader, du bruger), i så fald
ligger konfigurationen i /boot/grub/grub.conf

>
> Jeg har en anden ældre PC stående med en HD magen til i, og dens
> cmdline er fuldstændig magen til, men der sidder disken også som hdb,
> altså på samme controller som systemdisken. (Hvilket så ikke er
> optimalt, så det laver jeg måske om på en dag jeg har tid, og fået det
> til at virke i den PC jeg har problemer med nu.)

Du har sikkert haft en CD-brænder sidende som hdc
dengang du installerede. Ellers kan jeg ikke
gennemskue hvorfor installeren skulle konfigurere
kernen på den måde.

--
Kasper Dupont

---

Kasper Dupont <kasperd@daimi.au.dk> wrote:

>/proc/cmdline er slet ikke en fil, og du kan ikke
>ændre på den. I stedet skal du ændre på konfigurationen
>af din bootloader. Du bruger sikkert grub (ellers må
>du fortælle os hvilken loader, du bruger), i så fald
>ligger konfigurationen i /boot/grub/grub.conf

Fint, nu er den slettet og efter reboot reagerer fdisk også normalt og
genkender disken.
Men så skal jeg jo have delt disken oop, og det er lidt sparsomt med
hjælp der er til det.
Jeg har 300GB (sådan cirka) og jeg har 512 MB ram i maskinen, så en
swap-partition på 1-1,5 GB vil jo nok passe fint, men skal den ligge
først eller sidst på disken, og hvordan gør jeg det?
Og får maskinen til at bruge den swap i stedet for den der ligger
sidst på hda?
Resten af pladsen vil jeg gerne bare have til at være en stor, og så
kan jeg vel mounte den del som /var1/ og oprette filsystem med
mkfs.ext3, skal det være før eller efter mount?

Ja, det er første gang jeg gør noget der ligner dette i Linux, indtil
nu har jeg ladet installationsprogrammet om det.

>Du har sikkert haft en CD-brænder sidende som hdc
>dengang du installerede. Ellers kan jeg ikke
>gennemskue hvorfor installeren skulle konfigurere
>kernen på den måde.

Netop.

--
med venlig hilsen
Leonard - http://leonard.dk/

---

Leonard wrote:
>
> Jeg har 300GB (sådan cirka) og jeg har 512 MB ram i maskinen, så en
> swap-partition på 1-1,5 GB vil jo nok passe fint, men skal den ligge
> først eller sidst på disken, og hvordan gør jeg det?

Jeg ville lægge swap først på disken. Det er det nemmeste,
og på nogle harddiske er det vist også det hurtigste.
Personligt ville jeg sætte 2GB af til swap, men det er
nok bare mig. Du bruger fdisk til at oprette to partitioner
med n kommandoen.

Man kunne f.eks. angive følgende:
n (for en ny partition)
p (for en primær partition)
1 (partitionsnummer)
(tryk enter uden at skrive noget, som default startes den
nye partition i cylinder 1).
+1600M (ca. 1.5GB)
t (for at angive typen, da der kun er en partition vælges
den automatisk).
82 (typen for Linux swap)
n
p
2
(tryk derefter enter to gange, som default bruges resten
af pladsen til denne partition, og typen sættes til 83,
som bruges til alle Linux filsystemer).
w (Skriver ændringer til disken. Sørger for at kernen
tager den nye partitionstabel i brug med det samme,
med mindre nogle af de gamle er i brug. Og afslutter
fdisk.)

> Og får maskinen til at bruge den swap i stedet for den der ligger
> sidst på hda?

I /etc/fstab burde der stå en linie for din nuværende
swap partition. Du kan tilføje en ny linie for din nye
swap partition. Ved at sætte prioriteten kan du sikre,
at den gamle først tages i brug når den nye er fuld.
I options søjlen kunne der f.eks. stå pri=42, options
søjlen er den, hvor der står defaults på mange af
linierne.

Før en swap partition tages i brug skal der køres
mkswap på den. Du behøver ikke angive nogle options til
mkswap, dens defaults er fornuftige.

Når du har sat det op og kørt "swapon -a" (hvilket også
sker automatisk ved opstart), kan du se i /proc/swaps
hvilke swap partitioner, der er i brug.

> Resten af pladsen vil jeg gerne bare have til at være en stor, og så
> kan jeg vel mounte den del som /var1/ og oprette filsystem med
> mkfs.ext3, skal det være før eller efter mount?

Du kan ikke mounte partitionen før du har lavet et
filsystem.

>
> Ja, det er første gang jeg gør noget der ligner dette i Linux, indtil
> nu har jeg ladet installationsprogrammet om det.

Det er bare i orden. Men lad nu være med at gøre noget
dumt og slette alle dine data. Forkert brug af fdisk,
mkswap eller mkfs er en effektiv måde at lave skade på.

--
Kasper Dupont

---

Kasper Dupont <kasperd@daimi.au.dk> wrote:

>Jeg ville lægge swap først på disken. Det er det nemmeste,
>og på nogle harddiske er det vist også det hurtigste.

Jeg læste lidt på det i går og fik fdisk til at partitionere disken i
2 dele, en stor først på og en lille på ca 1,8GB tilsidst, så det
bliver sådan.
Jeg fik også oprettet filsystem på den store del og flyttet 46GB over,
så nu virker det som det skal.


>Når du har sat det op og kørt "swapon -a" (hvilket også
>sker automatisk ved opstart), kan du se i /proc/swaps
>hvilke swap partitioner, der er i brug.

Fin vejledning, og nu viser en cat /proc/swaps at der er 2 swap, hvor
den gamle har prioritet=-1 mens den nye har 42. Skal jeg ændre på den
gamle til et højere tal end 42, for at det bliver den nye der bruges,
eller kommer det af sig selv ved en genstart, da fdisk skrev at den
ikke kunne et-eller-andet, men det ville komme efter genstart?

Jeg har mounted en mappe på den nye store partition manuelt, huskes
det ved en genstart eller skal det skrives ind i en fil? - hvilken?

>Det er bare i orden. Men lad nu være med at gøre noget
>dumt og slette alle dine data. Forkert brug af fdisk,
>mkswap eller mkfs er en effektiv måde at lave skade på.

Ja, tak for advarslen, men jeg synes faktisk det virker mere sikkert
her på Linux end på windows, da jeg her altid angiver /dev/hdc1 eller
hvad den nu hedder, og dermed vel kun kan lave kage i den disk eller
partition jeg har angivet. Det er i hvert fald lykkedes uden at slette
noget

--
med venlig hilsen
Leonard - http://leonard.dk/

---

Leonard wrote:
>
> Fin vejledning, og nu viser en cat /proc/swaps at der er 2 swap, hvor
> den gamle har prioritet=-1 mens den nye har 42.

Jeg mener det er den med det største tal, der tages i brug
først. Og hvis prioriteten er den samme smides sider til
den, hvor der er mindst i brug. Du burde kunne se i
/proc/swaps, hvilken partition, der bliver lagt sider ned
på. Hold øje med used søjlen. Vær dog opmærksom på, at
der kan være blevet lagt sider ned på den med laveste
prioritet inden den anden blev aktiveret.

> Skal jeg ændre på den
> gamle til et højere tal end 42, for at det bliver den nye der bruges,
> eller kommer det af sig selv ved en genstart,

Hvis ikke man angiver noget bliver prioriteten sat i
nærheden af nul. Så den der er sat til 42 burde blive
brugt først.

> da fdisk skrev at den
> ikke kunne et-eller-andet, men det ville komme efter genstart?

Hvis der er noget i brug fra disken vil kernen ikke tage
en ny partitionstabel i brug. Dermed vil det stadigt være
den gamle, der bliver brugt. Du har forhåbentlig ikke
ændret partitionstabelen og lavet nogle filsystemer/
swappartitioner med det gamle layout.

>
> Jeg har mounted en mappe på den nye store partition manuelt, huskes
> det ved en genstart eller skal det skrives ind i en fil? - hvilken?

Nej, du skal tilføje den til /etc/fstab for at få den
mountet automatisk ved opstart.

>
> >Det er bare i orden. Men lad nu være med at gøre noget
> >dumt og slette alle dine data. Forkert brug af fdisk,
> >mkswap eller mkfs er en effektiv måde at lave skade på.
>
> Ja, tak for advarslen, men jeg synes faktisk det virker mere sikkert
> her på Linux end på windows, da jeg her altid angiver /dev/hdc1 eller
> hvad den nu hedder, og dermed vel kun kan lave kage i den disk eller
> partition jeg har angivet. Det er i hvert fald lykkedes uden at slette
> noget

Så længe du altid angiver hdc, så har jeg i hvert fald
ikke fantasi til at forestille mig, hvordan det skulle
kunne lade sig gøre at ødelægge noget på hda. Men pas dog
på med partitioneringen.

Overlappende partitioner er en skidt ting. Det kan også
gøre sig gældende, hvis man først har lavet en partitionering
og efterfølgende ændrer partitioneringen mens en af
partitionerne er i brug.

--
Kasper Dupont

---

Kasper Dupont <kasperd@daimi.au.dk> wrote:

>Nej, du skal tilføje den til /etc/fstab for at få den
>mountet automatisk ved opstart.

Hvordan skal den linie se ud?
Jeg forstår ikke logikken i:
LABEL=/var1 /var1 ext3 defaults 1 2

Er det tallene tilsidst der fortæller hvilken disk der mountes på og
så skal det være 2 1 da det er disk 2 partition 1 ?


--
med venlig hilsen
Leonard - http://leonard.dk/

---

Leonard wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> wrote:
>
> >Nej, du skal tilføje den til /etc/fstab for at få den
> >mountet automatisk ved opstart.
>
> Hvordan skal den linie se ud?
> Jeg forstår ikke logikken i:
> LABEL=/var1 /var1 ext3 defaults 1 2

Jeg havde ikke lige tænkt på, at installeren brugte
labels i /etc/fstab. Jeg synes det er en dårlig idé,
og jeg plejer selv at ændre det ved første lejlighed.

Det er nu ikke noget problem, du kan sagtens lade de
eksisterende linier blive ved med at bruge labels, og
angive device for din nye linie.

Det første felt angiver hvilket device (hvilken
partition), der skal mountes. LABEL=navn betyder, at
mount skal kigge alle partitioner igennem for at
finde en med navnet navn. I stedet for kunne man bare
angive navnet på en partition f.eks. /dev/hdc1.

De næste tre felter angiver mountpoint, filsystem og
options.

De sidste to felter fortæller noget om hvordan der
skal checkes filsystemer under opstart. Normalt står
der 1 1 ved rod filsystemet, og 1 2 ved alle andre
filsystemer, der skal checkes ved opstart. Der skal
stå 0 0 ved filsystemer, der ikke skal checkes. Jeg
vil anbefale, at du skriver 1 2 ved dit nye filsystem.

>
> Er det tallene tilsidst der fortæller hvilken disk der mountes på og
> så skal det være 2 1 da det er disk 2 partition 1 ?

Nej, overhovedet ikke.

--
Kasper Dupont

---

Kasper Dupont <kasperd@daimi.au.dk> wrote:

>Det første felt angiver hvilket device (hvilken
>partition), der skal mountes. LABEL=navn betyder, at
>mount skal kigge alle partitioner igennem for at
>finde en med navnet navn. I stedet for kunne man bare
>angive navnet på en partition f.eks. /dev/hdc1.
>
>De næste tre felter angiver mountpoint, filsystem og
>options.
>
>De sidste to felter fortæller noget om hvordan der
>skal checkes filsystemer under opstart. Normalt står
>der 1 1 ved rod filsystemet, og 1 2 ved alle andre
>filsystemer, der skal checkes ved opstart. Der skal
>stå 0 0 ved filsystemer, der ikke skal checkes. Jeg
>vil anbefale, at du skriver 1 2 ved dit nye filsystem.

Så jeg altså sætter en linie ind i /etc/fstab der ligner denne:
LABEL=/dev/hdc1 /var1 ext3 defaults 1 2

>> Er det tallene tilsidst der fortæller hvilken disk der mountes på og
>> så skal det være 2 1 da det er disk 2 partition 1 ?
>
>Nej, overhovedet ikke.

OK, det er forstået udfra din fine forklaring ovenfor.

--
med venlig hilsen
Leonard - http://leonard.dk/

---

Leonard wrote:
>
> Så jeg altså sætter en linie ind i /etc/fstab der ligner denne:
> LABEL=/dev/hdc1 /var1 ext3 defaults 1 2

Næsten, der skal ikke stå noget med label. I øvrigt
synes jeg navnet på dit mountpoint er lidt specielt,
men det må du selvfølgelig selv om.

/dev/hdc1 /var1 ext3 defaults 1 2

--
Kasper Dupont

---

Kasper Dupont <kasperd@daimi.au.dk> wrote:

>Næsten, der skal ikke stå noget med label. I øvrigt
>synes jeg navnet på dit mountpoint er lidt specielt,
>men det må du selvfølgelig selv om.

Tjah, der er jo en /var hvor alle de filer der ændrer sig undervejs
ligger nu, fx i /var/www/html og der havde jeg også lagt /var/film som
er den mappe der i første omgang skal ligge på det nye drev, og jeg
kan vel ikke have 2 mapper der hedder /var så jeg tænkte at det
nemmeste var at kalde den nye for /var1

Mange tak for hjælpen, jeg tror jeg vil forsøge at samle det i en
lille guide, så kan jeg selv huske det næste gang og andre kan måske
få glæde af det. Jeg spørger lige her når den er klar til at blive
kontrolleret for fejl og mangler.

--
med venlig hilsen
Leonard - http://leonard.dk/

---

Leonard wrote:

> Tjah, der er jo en /var hvor alle de filer der ændrer sig undervejs
> ligger nu, fx i /var/www/html og der havde jeg også lagt /var/film som
> er den mappe der i første omgang skal ligge på det nye drev, og jeg
> kan vel ikke have 2 mapper der hedder /var så jeg tænkte at det
> nemmeste var at kalde den nye for /var1

Du behøves ikke at have den nye disk i / jeg har f.eks. min ene disk som /
og den anden som /var/spool .

--
Med venlig hilsen

Ivar Madsen

---

Kasper Dupont wrote:

> De sidste to felter fortæller noget om hvordan der
> skal checkes filsystemer under opstart. Normalt står
> der 1 1 ved rod filsystemet, og 1 2 ved alle andre
> filsystemer, der skal checkes ved opstart. Der skal
> stå 0 0 ved filsystemer, der ikke skal checkes. Jeg
> vil anbefale, at du skriver 1 2 ved dit nye filsystem.

Hvad gør den så hvis der står 2 2 ?

Brokker sig over en ulovlig parmeter?

--
Med venlig hilsen

Ivar Madsen

---

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

> Kasper Dupont wrote:
>
> > De sidste to felter fortæller noget om hvordan der
> > skal checkes filsystemer under opstart. Normalt står
> > der 1 1 ved rod filsystemet, og 1 2 ved alle andre
> > filsystemer, der skal checkes ved opstart. Der skal
> > stå 0 0 ved filsystemer, der ikke skal checkes. Jeg
> > vil anbefale, at du skriver 1 2 ved dit nye filsystem.
>
> Hvad gør den så hvis der står 2 2 ?
>
> Brokker sig over en ulovlig parmeter?

Næh. Det første tal er fsck uvedkommende, men styrer backupfrekvensen
for dump(8). Det er lettere uklart hvordan det præcis fungerer; "man
fstab" er ret tåget, "man dump" ligeså, men Google fandt en der påstod
at enheden er dage...

--
O__ ---- Peter Dalgaard Blegdamsvej 3
c/ /'_ --- Dept. of Biostatistics 2200 Cph. N
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907

---

Peter Dalgaard wrote:
>
> Næh. Det første tal er fsck uvedkommende, men styrer backupfrekvensen
> for dump(8). Det er lettere uklart hvordan det præcis fungerer; "man
> fstab" er ret tåget, "man dump" ligeså, men Google fandt en der påstod
> at enheden er dage...

OK, hvem bruger overhovedet dump til at tage backups.
I øvrigt her er hvad Linus selv har at sige om dump:

So anybody who depends on "dump" getting backups right
is already playing russian rulette with their backups.

--
Kasper Dupont

---

Kasper Dupont <kasperd@daimi.au.dk> writes:

> So anybody who depends on "dump" getting backups right
> is already playing russian rulette with their backups.

Det afhænger sandelig af platformen, og hvorvidt der er metadata i
filsystemet som fx GNU tar eller cpio ikke kender til.

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus

---

Kasper Dupont <kasperd@daimi.au.dk> writes:

> Peter Dalgaard wrote:
> >
> > Næh. Det første tal er fsck uvedkommende, men styrer backupfrekvensen
> > for dump(8). Det er lettere uklart hvordan det præcis fungerer; "man
> > fstab" er ret tåget, "man dump" ligeså, men Google fandt en der påstod
> > at enheden er dage...
>
> OK, hvem bruger overhovedet dump til at tage backups.

Jeg gør, det virker fint. Jeg har et system hvor der bliver taget
backup hver dag og umiddelbart efter backupen er taget bliver den
pakket ud på en anden maskine, det virker helt uden problemer.

Det jeg godt kan lide ved dump som jeg ikke har fundet til tar/cpio er
'restore i' funktionen hvor man kan gå ind i en dumpfil og markere de
filer man godt vil have pakket ud.

> I øvrigt her er hvad Linus selv har at sige om dump:
>
> So anybody who depends on "dump" getting backups right
> is already playing russian rulette with their backups.

Der er en længere forklaring her:
http://dump.sourceforge.net/isdumpdeprecated.html

--
Kim Hansen | |\ _,,,---,,_ | Det er ikke
Vadgårdsvej 3, 2.tv. | /,`.-´` -. ;:-. | Jeopardy.
2860 Søborg | |,4- ) )-,_. ,\ ( `'-' | Svar _efter_
Tlf: 39 56 24 37 | '---''(_/--' `-'\_) | spørgsmålet.

---

Kim Hansen wrote:
>
> Jeg gør, det virker fint. Jeg har et system hvor der bliver taget
> backup hver dag og umiddelbart efter backupen er taget bliver den
> pakket ud på en anden maskine, det virker helt uden problemer.

OK, jeg betvivler ikke, at dump sikkert virker fint i de
fleste tilfælde. Der er bare en risiko for problemer.

>
> Det jeg godt kan lide ved dump som jeg ikke har fundet til tar/cpio er
> 'restore i' funktionen hvor man kan gå ind i en dumpfil og markere de
> filer man godt vil have pakket ud.

OK, det lyder umiddelbart smart nok. Men det burde ikke
være svært at lave noget tilsvarende til tar. Jeg har
selv overvejet at lave nogle værktøjer som kan gøre noget
i den retning. Skal jeg nævne det her i gruppen, når jeg
har noget, der kan bruges?

>
> Der er en længere forklaring her:
> http://dump.sourceforge.net/isdumpdeprecated.html

Glimrende forklaring. Jeg har lige et par kommentarer:

Hvad angår tilgang gennem blockdevices, så burde den
tilgang gå gennem cachen. Hvis man designer cachen
omhyggeligt, så kan jeg ikke se, hvorfor man ikke skulle
kunne undgå alle de problemer, der er relateret til
caching. Problemer relateret til ændringer af filsystemet
er en helt anden sag.

Diskussionen af alle de problemer, der kan være ved en
backup rutine, er god læsning. Det er fornuftigt at holde
øje med den slags potentielle problemer.

Problemet omkring atime synes jeg ikke det i sig selv er
et godt argument for at bruge dump. At man kan bruge
noatime mens backupen kører er selvfølgelig delvist en
løsning, men det ville være smartere, hvis man kunne
gøre det så det kun påvirkede den ene process.

Det forklares også, hvordan ctime kan bruges til at
afgøre, om en fil skal backupkopieres. Men man kan ændre
en fils indhold uden at ændre ctime. (Det er muligvis en
bug).

Brugen af snapshots som bliver diskuteret til sidst er
en god idé. (Jeg sad selv og tænkte på det, da jeg var
nået halvvejs gennem dokumentet). Så vidt jeg lige kan
se vil snapshots løse hovedparten af de problemer, som
dokumentet omtaler.

Det er utvivlsomt nemmere at lave snapshots på blockdevice
niveau end på filsystems niveau. Det argument bliver ikke
fremført, men det er ellers det bedste argument jeg kan
komme i tanke om for, at dump kan være en god idé.

Hvad er formatet af de filer dump producerer? Hvilken
metode, der anvendes til at læse filsystemet, og
formatet af outputet burde i nogen udstrækning være
uafhængige af hinanden.

--
Kasper Dupont

---

Kasper Dupont <kasperd@daimi.au.dk> writes:

> Kim Hansen wrote:
> >
> > Det jeg godt kan lide ved dump som jeg ikke har fundet til tar/cpio er
> > 'restore i' funktionen hvor man kan gå ind i en dumpfil og markere de
> > filer man godt vil have pakket ud.
>
> OK, det lyder umiddelbart smart nok. Men det burde ikke
> være svært at lave noget tilsvarende til tar. Jeg har
> selv overvejet at lave nogle værktøjer som kan gøre noget
> i den retning. Skal jeg nævne det her i gruppen, når jeg
> har noget, der kan bruges?

Klart nok, det er altid spændende at høre om nye værktøjer.

En del af funktionaliteten ligger allerede i mc eller i diverse
desktop environments (f.eks. FileRoller til Gnome), men der mangler
såvidt jeg kan se muligheder for at markere filer og foldere mange
forskellige steder og derefter starte udpakningen.

Et grundlæggende problem med tar i forhold til dump er at tar har
information om alle de filer der ligger i et arkiv liggende spredt ud
i hele arkivet, dvs. at man skal læse hele arkivet for at kunne gå
igang med at udvælge filer til udpakning. Det kan tage meget lang tid
hvis man har pakket et par gigabyte. I dump ligger den slags
information først i dump-filen.

> Problemet omkring atime synes jeg ikke det i sig selv er
> et godt argument for at bruge dump. At man kan bruge
> noatime mens backupen kører er selvfølgelig delvist en
> løsning, men det ville være smartere, hvis man kunne
> gøre det så det kun påvirkede den ene process.

Måske kan man lave et trick med bind mount (under Linux) som giver en
alternativ tilgang til filsysteme som så er noatime.

> Det forklares også, hvordan ctime kan bruges til at
> afgøre, om en fil skal backupkopieres. Men man kan ændre
> en fils indhold uden at ændre ctime. (Det er muligvis en
> bug).

Hvordan gør man det?

> Brugen af snapshots som bliver diskuteret til sidst er
> en god idé. (Jeg sad selv og tænkte på det, da jeg var
> nået halvvejs gennem dokumentet). Så vidt jeg lige kan
> se vil snapshots løse hovedparten af de problemer, som
> dokumentet omtaler.
>
> Det er utvivlsomt nemmere at lave snapshots på blockdevice
> niveau end på filsystems niveau. Det argument bliver ikke
> fremført, men det er ellers det bedste argument jeg kan
> komme i tanke om for, at dump kan være en god idé.

Lige nu tager jeg backup med dump af mountede filsystemer, og jeg ved
der er en risiko som jeg har valgt at leve med. Hvis den risiko ikke
var accetabel ville jeg nok bruge LVM til at lave et snapshot som jeg
derefter kunne køre fsck på for at rydde op i inden jeg lavede mit
dump.

> Hvad er formatet af de filer dump producerer? Hvilken
> metode, der anvendes til at læse filsystemet, og
> formatet af outputet burde i nogen udstrækning være
> uafhængige af hinanden.

Formatet er dumps eget, og dermed tror jeg også at det er knyttet til
ext2. Udpakningen af en dump-fil foregår dog ved hjælp af helt
almindelige fil-operationer, dvs. at man godt kan udpakke et
dump-arkiv af et ext2-filsystem på et XFS eller Reiser-filsystem.

--
Kim Hansen | |\ _,,,---,,_ | Det er ikke
Vadgårdsvej 3, 2.tv. | /,`.-´` -. ;:-. | Jeopardy.
2860 Søborg | |,4- ) )-,_. ,\ ( `'-' | Svar _efter_
Tlf: 39 56 24 37 | '---''(_/--' `-'\_) | spørgsmålet.

---

Kim Hansen wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> writes:
>
> > Kim Hansen wrote:
> > >
> > > Det jeg godt kan lide ved dump som jeg ikke har fundet til tar/cpio er
> > > 'restore i' funktionen hvor man kan gå ind i en dumpfil og markere de
> > > filer man godt vil have pakket ud.
> >
> > OK, det lyder umiddelbart smart nok. Men det burde ikke
> > være svært at lave noget tilsvarende til tar. Jeg har
> > selv overvejet at lave nogle værktøjer som kan gøre noget
> > i den retning. Skal jeg nævne det her i gruppen, når jeg
> > har noget, der kan bruges?
>
> Klart nok, det er altid spændende at høre om nye værktøjer.

Jeg kan da lige nævne hvad jeg har af idéer. En af dem
er en filsystems driver til Linux, som kan mounte en
tar fil. En anden idé er et værktøj, som kan læse en
tar fil fra stdin og spytte en ny tar fil med udvalgte
filer ud på stdout. Med en passende frontend kunne
sådan et værktøj også bruges til at opnå en del af den
funktionalitet du efterlyser.

Hvad jeg allerede har lavet og som blot mangler lidt
finpudsning er et arkiveringsprogram, som er designet
til at kunne arkivere tar filer. Jeg bruger det selv
til mine daglige backups. Jeg gemmer så alle gamle tar
filer, og arkiveringsværktøjet undersøger så selv for
hver enkelt blok, om den allerede findes i arkivet, og
hvis den gør laver blot en pointer til den eksisterende
udgave. Så selvom jeg har sammenlagt 194GB tar filer
fylder arkivet kun 4.3GB.

>
> En del af funktionaliteten ligger allerede i mc eller i diverse
> desktop environments (f.eks. FileRoller til Gnome), men der mangler
> såvidt jeg kan se muligheder for at markere filer og foldere mange
> forskellige steder og derefter starte udpakningen.

OK, jeg vil overveje at lave et værktøj, som giver
mulighed for at foretage den markering og så enten
generere en ny tar fil med de valgte filer eller
pakke dem ud.

>
> Et grundlæggende problem med tar i forhold til dump er at tar har
> information om alle de filer der ligger i et arkiv liggende spredt ud
> i hele arkivet, dvs. at man skal læse hele arkivet for at kunne gå
> igang med at udvælge filer til udpakning. Det kan tage meget lang tid
> hvis man har pakket et par gigabyte. I dump ligger den slags
> information først i dump-filen.

OK, det er så et argument for at dump formatet er
bedre end tar formatet. Men som jeg nævnte tidligere,
så er formatet og metoden til at læse filsystemet
uafhængige af hinanden. Der er i øvrigt flere formater
at vælge imellem, man kan også overveje cpio.

Jeg synes også tars håndtering af metadata er et
problem. Specielt da jeg overvejer at mounte en tar fil
som et filsystem. Der er tilgengæld en stor fordel ved
tar formatet. Dens brug af 512 bytes blokke giver i
første omgang lidt overflødig spilplads. Men det er
netop denne indeling i blokke, som gør at mit værktøj
kan arkivere dem så effektivt. Det gør det også nemmere
at lave en filsystems driver, der kan mounte arkivet.

Er her nogen som ved, om dump og cpio bruger 512 bytes
blokke?

>
> > Problemet omkring atime synes jeg ikke det i sig selv er
> > et godt argument for at bruge dump. At man kan bruge
> > noatime mens backupen kører er selvfølgelig delvist en
> > løsning, men det ville være smartere, hvis man kunne
> > gøre det så det kun påvirkede den ene process.
>
> Måske kan man lave et trick med bind mount (under Linux) som giver en
> alternativ tilgang til filsysteme som så er noatime.

Jeg overvejede muligheden, for det ville da være smart.
Men jeg tror desværre ikke det virker, endnu. Forhåbentlig
giver næste version mulighed for at sætte ting som
noatime, ro/rw, suid/nosuid, dev/nodev, osv. seperat for
hvert bindmount. Hvis man også kan gøre det med uid og gid
for de filsystemer, der har den slags options, så vil det
være endnu smartere.

>
> > Det forklares også, hvordan ctime kan bruges til at
> > afgøre, om en fil skal backupkopieres. Men man kan ændre
> > en fils indhold uden at ændre ctime. (Det er muligvis en
> > bug).
>
> Hvordan gør man det?

Gennem en memory mapping.

>
> Lige nu tager jeg backup med dump af mountede filsystemer, og jeg ved
> der er en risiko som jeg har valgt at leve med. Hvis den risiko ikke
> var accetabel ville jeg nok bruge LVM til at lave et snapshot som jeg
> derefter kunne køre fsck på for at rydde op i inden jeg lavede mit
> dump.

Jeg synes det ville være smart, hvis man kunne gøre noget
tilsvarende for vilkårlige blockdevices. Men det kommer
nok til at kræve nogle ikke trivielle ændringer i kernen.

>
> Formatet er dumps eget, og dermed tror jeg også at det er knyttet til
> ext2.

OK, men jeg har nok brug for at kende det lidt bedre hvis
jeg skal have mine værktøjer til at kunne noget smart med
dump filer. Men hvis jeg skal sætte mig ind i både tar,
cpio og dump, så får jeg da noget at se til.

> Udpakningen af en dump-fil foregår dog ved hjælp af helt
> almindelige fil-operationer, dvs. at man godt kan udpakke et
> dump-arkiv af et ext2-filsystem på et XFS eller Reiser-filsystem.

OK. Det er nok også det bedste. I få tilfælde kunne man
måske ønske at kunne restore direkte til en blockdevice.
Men mkfs først og så restore vha. almindelige fil
operationer er nok bedre i de fleste tilfælde.

--
Kasper Dupont

---

Kasper Dupont <kasperd@daimi.au.dk> writes:

> Kim Hansen wrote:
> >
>
> Jeg kan da lige nævne hvad jeg har af idéer. En af dem
> er en filsystems driver til Linux, som kan mounte en
> tar fil.

Det findes allerede i mange version, f.eks. fuse.sf.net. Problemet er
at det kræver at man roder med kernen og det ville jeg gerne undgå.

> > Lige nu tager jeg backup med dump af mountede filsystemer, og jeg ved
> > der er en risiko som jeg har valgt at leve med. Hvis den risiko ikke
> > var accetabel ville jeg nok bruge LVM til at lave et snapshot som jeg
> > derefter kunne køre fsck på for at rydde op i inden jeg lavede mit
> > dump.
>
> Jeg synes det ville være smart, hvis man kunne gøre noget
> tilsvarende for vilkårlige blockdevices. Men det kommer
> nok til at kræve nogle ikke trivielle ændringer i kernen.

Man kan vel lægge LVM oven på vilkårlige block-devices. Et eller andet
sted skal man kunne gemme forskellen på snapshottet og originalen, så
jeg tror ikke man kommer uden om et LVM-lag.

--
Kim Hansen | |\ _,,,---,,_ | Det er ikke
Vadgårdsvej 3, 2.tv. | /,`.-´` -. ;:-. | Jeopardy.
2860 Søborg | |,4- ) )-,_. ,\ ( `'-' | Svar _efter_
Tlf: 39 56 24 37 | '---''(_/--' `-'\_) | spørgsmålet.

---

Kim Hansen wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> writes:
>
> > Kim Hansen wrote:
> > >
> >
> > Jeg kan da lige nævne hvad jeg har af idéer. En af dem
> > er en filsystems driver til Linux, som kan mounte en
> > tar fil.
>
> Det findes allerede i mange version, f.eks. fuse.sf.net. Problemet er
> at det kræver at man roder med kernen og det ville jeg gerne undgå.

Men fuse kører faktisk en del af koden i user mode.
Hvor meget, der kører i kernen ved jeg ikke. Min idé
er derimod at lave det hele i kernen og gøre brug af
en block mapping for at opnå en simpel og effektiv
implementation. Jeg har også en idé til, hvordan man
kan lave en block mapping hvor filsystemet stadig er
skrevet delvist i user mode kode.

Er der nogen som har erfaringer med effektiviteten
af store tar filer med fuse? Her tænker jeg på tar
filer i størelsesordenen 3GB på en maskine med 256MB
ram.

Findes der nogle implementationer til mounting af
tar filer, som gør brug af block mapping?

>
> Man kan vel lægge LVM oven på vilkårlige block-devices. Et eller andet
> sted skal man kunne gemme forskellen på snapshottet og originalen, så
> jeg tror ikke man kommer uden om et LVM-lag.

Min tanke var et midlertidigt snapshot. Altså et,
der kun eksisterer så længe man kører sin dump
process. Hvis maskinen bliver genstartet undervejs
bliver man nødt til at starte forfra. Jeg havde så
tænkt mig, at man kunne gemme forskellene i RAM og
swap.

Hvad der så skal ske hvis man ikke har mere plads
har jeg ikke noget godt bud på. Men det problem må
LVM vel også skulle tage stilling til.

--
Kasper Dupont

---

Kasper Dupont <kasperd@daimi.au.dk> writes:

> Kim Hansen wrote:
> >
> > Det findes allerede i mange version, f.eks. fuse.sf.net. Problemet er
> > at det kræver at man roder med kernen og det ville jeg gerne undgå.
>
> Men fuse kører faktisk en del af koden i user mode.
> Hvor meget, der kører i kernen ved jeg ikke. Min idé
> er derimod at lave det hele i kernen og gøre brug af
> en block mapping for at opnå en simpel og effektiv
> implementation. Jeg har også en idé til, hvordan man
> kan lave en block mapping hvor filsystemet stadig er
> skrevet delvist i user mode kode.

Det lyder spændende, men stadig lidt for experimentelt til at jeg
ville turde bruge det i produktion.

> > Man kan vel lægge LVM oven på vilkårlige block-devices. Et eller andet
> > sted skal man kunne gemme forskellen på snapshottet og originalen, så
> > jeg tror ikke man kommer uden om et LVM-lag.
>
> Min tanke var et midlertidigt snapshot. Altså et,
> der kun eksisterer så længe man kører sin dump
> process. Hvis maskinen bliver genstartet undervejs
> bliver man nødt til at starte forfra. Jeg havde så
> tænkt mig, at man kunne gemme forskellene i RAM og
> swap.

Det er selvfølgelig en mulighed, men jeg ville bare være bange for at
OOM-killeren kommer en tur forbi hvis noget går galt...

> Hvad der så skal ske hvis man ikke har mere plads
> har jeg ikke noget godt bud på. Men det problem må
> LVM vel også skulle tage stilling til.

Jeg testede lige hvordan det er under LVM. Når man laver sit snapshot
vælger man hvor meget plads man vil sætte af til ændringene, hvis
denne plads bliver brugt op kører originalen videre uden problemer
mens kopien låser totalt.

Det vil betyde at man skal starte forfra med backupen hvis pladsen
bliver brugt op, men man laver ikke nogen problemer for de kørende
processer. Hvis man mens backupen kører bliver opmærksom på at pladsen
er ved at løbe ud kan man udvide den med lvextend.

--
Kim Hansen | |\ _,,,---,,_ | Det er ikke
Vadgårdsvej 3, 2.tv. | /,`.-´` -. ;:-. | Jeopardy.
2860 Søborg | |,4- ) )-,_. ,\ ( `'-' | Svar _efter_
Tlf: 39 56 24 37 | '---''(_/--' `-'\_) | spørgsmålet.

---

Kim Hansen wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> writes:
>
> > Kim Hansen wrote:
> > >
> > > Det findes allerede i mange version, f.eks. fuse.sf.net. Problemet er
> > > at det kræver at man roder med kernen og det ville jeg gerne undgå.
> >
> > Men fuse kører faktisk en del af koden i user mode.
> > Hvor meget, der kører i kernen ved jeg ikke. Min idé
> > er derimod at lave det hele i kernen og gøre brug af
> > en block mapping for at opnå en simpel og effektiv
> > implementation. Jeg har også en idé til, hvordan man
> > kan lave en block mapping hvor filsystemet stadig er
> > skrevet delvist i user mode kode.
>
> Det lyder spændende, men stadig lidt for experimentelt til at jeg
> ville turde bruge det i produktion.

Min idé er vel ikke mere eksperimentel end fuse?
Bortset fra at jeg ikke har implementeret noget
endnu. Mener du i øvrigt det er mere eksperimentelt
fordi det inkluderer user mode kode fremfor en ren
kerne løsning?

>
> > > Man kan vel lægge LVM oven på vilkårlige block-devices. Et eller andet
> > > sted skal man kunne gemme forskellen på snapshottet og originalen, så
> > > jeg tror ikke man kommer uden om et LVM-lag.
> >
> > Min tanke var et midlertidigt snapshot. Altså et,
> > der kun eksisterer så længe man kører sin dump
> > process. Hvis maskinen bliver genstartet undervejs
> > bliver man nødt til at starte forfra. Jeg havde så
> > tænkt mig, at man kunne gemme forskellene i RAM og
> > swap.
>
> Det er selvfølgelig en mulighed, men jeg ville bare være bange for at
> OOM-killeren kommer en tur forbi hvis noget går galt...

Man skal selvfølgelig sørge for at ikke bruge for
meget plads.

>
> > Hvad der så skal ske hvis man ikke har mere plads
> > har jeg ikke noget godt bud på. Men det problem må
> > LVM vel også skulle tage stilling til.
>
> Jeg testede lige hvordan det er under LVM. Når man laver sit snapshot
> vælger man hvor meget plads man vil sætte af til ændringene, hvis
> denne plads bliver brugt op kører originalen videre uden problemer
> mens kopien låser totalt.
>
> Det vil betyde at man skal starte forfra med backupen hvis pladsen
> bliver brugt op, men man laver ikke nogen problemer for de kørende
> processer. Hvis man mens backupen kører bliver opmærksom på at pladsen
> er ved at løbe ud kan man udvide den med lvextend.

Det var også noget i den retning jeg ville have
gjort. Forhåbentlig får man sjældent brug for at
genstarte sin backup.

--
Kasper Dupont

---

Kasper Dupont <kasperd@daimi.au.dk> writes:

> Kim Hansen wrote:
> >
> > Kasper Dupont <kasperd@daimi.au.dk> writes:
> >
> > > Kim Hansen wrote:
> > > >
> > > > Det findes allerede i mange version, f.eks. fuse.sf.net. Problemet er
> > > > at det kræver at man roder med kernen og det ville jeg gerne undgå.
> > >
> > > Men fuse kører faktisk en del af koden i user mode.
> > > Hvor meget, der kører i kernen ved jeg ikke. Min idé
> > > er derimod at lave det hele i kernen og gøre brug af
> > > en block mapping for at opnå en simpel og effektiv
> > > implementation. Jeg har også en idé til, hvordan man
> > > kan lave en block mapping hvor filsystemet stadig er
> > > skrevet delvist i user mode kode.
> >
> > Det lyder spændende, men stadig lidt for experimentelt til at jeg
> > ville turde bruge det i produktion.
>
> Min idé er vel ikke mere eksperimentel end fuse?
> Bortset fra at jeg ikke har implementeret noget
> endnu. Mener du i øvrigt det er mere eksperimentelt
> fordi det inkluderer user mode kode fremfor en ren
> kerne løsning?

Jeg anså nu stadig fuse for at være eksperimentelt, men kan godt se at
de selv på SourceForge skriver at det er klar til produktion. Jeg må
hellere kigge på det igen, det kan jo være at det er blevet mere modent.

Jeg forstod din oprindelige beskrivelse om block mapping som om hele
udpakningen af tar-filerne skulle ske i kernel space, og det tror jeg
på ville være mere risikofyldt end hvis man lavede dele i user space.

Kan du ikke lave din tar-udpakning som en forbedring af fuse?

--
Kim Hansen | |\ _,,,---,,_ | Det er ikke
Vadgårdsvej 3, 2.tv. | /,`.-´` -. ;:-. | Jeopardy.
2860 Søborg | |,4- ) )-,_. ,\ ( `'-' | Svar _efter_
Tlf: 39 56 24 37 | '---''(_/--' `-'\_) | spørgsmålet.

---

On Mon, 22 Nov 2004 16:47:11 +0100, Kasper Dupont
<kasperd@daimi.au.dk> wrote:

>Kim Hansen wrote:
>>
>> Kasper Dupont <kasperd@daimi.au.dk> writes:
>>
>> > Kim Hansen wrote:
>> > >
>> >
>> > Jeg kan da lige nævne hvad jeg har af idéer. En af dem
>> > er en filsystems driver til Linux, som kan mounte en
>> > tar fil.
>>
>> Det findes allerede i mange version, f.eks. fuse.sf.net. Problemet er
>> at det kræver at man roder med kernen og det ville jeg gerne undgå.
>
>Men fuse kører faktisk en del af koden i user mode.
>Hvor meget, der kører i kernen ved jeg ikke. Min idé
>er derimod at lave det hele i kernen og gøre brug af
>en block mapping for at opnå en simpel og effektiv
>implementation. Jeg har også en idé til, hvordan man
>kan lave en block mapping hvor filsystemet stadig er
>skrevet delvist i user mode kode.
>
En ren kernel implementation eksisterer også allerede.
d. 6. november blev en opdateret udgave af tarfs til 2.6.x postet på
linux-kernel:
From: andyliu <liudeyan domain is gmail dot com>
Subject: [PATCH]a tar filesystem for 2.6.10-rc1-mm3

-tgc

---

Kim Hansen wrote:
>
> Jeg anså nu stadig fuse for at være eksperimentelt, men kan godt se at
> de selv på SourceForge skriver at det er klar til produktion. Jeg må
> hellere kigge på det igen, det kan jo være at det er blevet mere modent.

Jeg har ikke prøvet det, så jeg vil ikke udtale mig om
modenheden. Men der står det virker på både 2.4 og 2.6,
så jeg må hellere tage et kig på det. Min egen kode,
som pt. virker fint på 2.4, kan slet ikke compileres
til 2.6. Det kan være fuse om ikke andet kan lære mig,
hvad jeg gør galt.

>
> Jeg forstod din oprindelige beskrivelse om block mapping som om hele
> udpakningen af tar-filerne skulle ske i kernel space, og det tror jeg
> på ville være mere risikofyldt end hvis man lavede dele i user space.

Jeg har vist ikke sagt noget om udpakning. Der er
forskellige risici ved at lave en ren kerne løsning
og en kombineret kerne+user mode løsning.

En kombineret løsning betyder en risiko for cykliske
afhængigheder og deadlocks. Men hvis ellers kerne
delen er robust, så vil fejl i user mode delen i værste
fald betyde, at programmer får fejl ved læsning fra
dette ene filsystem.

En ren kerne version kræver (måske) mere kode i kernen,
og dermed er der større risiko for fejl som kan skade
kernens integritet.

>
> Kan du ikke lave din tar-udpakning som en forbedring af fuse?

Næppe. Der er jo fundamentale forskelle i designet.
Jeg formoder at fuse slet ikke bruger block devices.

--
Kasper Dupont

---

Tom Gravgaard Christensen wrote:
>
> En ren kernel implementation eksisterer også allerede.
> d. 6. november blev en opdateret udgave af tarfs til 2.6.x postet på
> linux-kernel:
> From: andyliu <liudeyan domain is gmail dot com>
> Subject: [PATCH]a tar filesystem for 2.6.10-rc1-mm3

Ved første øjekast ser den ud til at være lavet på ca.
samme måde som jeg ville gøre det. Så er der jo ingen
grund til at jeg går i gang med at skrive det helt fra
grunden. Så må jeg jo i gang med at reviewe koden, den
ser godt nok lidt mere compliceret ud end jeg havde
forestillet mig.

http://www.google.com/groups?selm=2XOfS-1U6-1%40gated-at.bofh.it

--
Kasper Dupont

---

Kasper Dupont wrote:
>
> Tom Gravgaard Christensen wrote:
> >
> > En ren kernel implementation eksisterer også allerede.
> > d. 6. november blev en opdateret udgave af tarfs til 2.6.x postet på
> > linux-kernel:
> > From: andyliu <liudeyan domain is gmail dot com>
> > Subject: [PATCH]a tar filesystem for 2.6.10-rc1-mm3
[...]
>
> http://www.google.com/groups?selm=2XOfS-1U6-1%40gated-at.bofh.it

Der ligger to udgaver, og i begge tilfælde er der gået
noget galt med formateringen, så patchen ikke virker.
Er der nogen som har en fornemmelse af, hvorvidt, der
er andre forskelle?

Jeg tog den første, som så bedst ud og rettede
formateringen. Den ligger her såfremt nogen har lyst
til at kigge nærmere på den:

http://brics.dk/~kasperd/linux_kernel/linux-2.6.10-rc1-tarfs.patch

--
Kasper Dupont

---

Tom Gravgaard Christensen wrote:
>
> En ren kernel implementation eksisterer også allerede.
> d. 6. november blev en opdateret udgave af tarfs til 2.6.x postet på
> linux-kernel:

Jeg har kigget koden igennem. Designet er fornuftigt nok.

Der er et par detaljer som ikke er supporteret endnu. Den
kan ikke håndtere device inodes, named pipes, ol. Det vil
jeg selv prøve at implementere. Det kan ikke være svært.

Desuden er der ikke support for sparse filer, den ser dog
ud til at forsøge på at springe over dem, så man stadig
kan tilgå resten af filerne i arkivet. Det vil jeg teste
så snart jeg kommer hjem til min 2.6 maskine.

Endeligt har jeg undret mig lidt over at tar arkivet
parses ved første read_inode kald. Det er selvfølgelig
nødvendigt at parse hele arkivet før man kan se noget som
helst, og det skal naturligvis kun gøres én gang. Men det
ser alligevel ud til at ske inden fill_root retunerer, så
hvorfor bliver det ikke bare gjort direkte fra fill_root?

--
Kasper Dupont

---

Kim Hansen <k-spam2003@oek.dk> writes:

> Kasper Dupont <kasperd@daimi.au.dk> writes:
>
> > Brugen af snapshots som bliver diskuteret til sidst er
> > en god idé. (Jeg sad selv og tænkte på det, da jeg var
> > nået halvvejs gennem dokumentet). Så vidt jeg lige kan
> > se vil snapshots løse hovedparten af de problemer, som
> > dokumentet omtaler.
> >
> > Det er utvivlsomt nemmere at lave snapshots på blockdevice
> > niveau end på filsystems niveau. Det argument bliver ikke
> > fremført, men det er ellers det bedste argument jeg kan
> > komme i tanke om for, at dump kan være en god idé.
>
> Lige nu tager jeg backup med dump af mountede filsystemer, og jeg ved
> der er en risiko som jeg har valgt at leve med. Hvis den risiko ikke
> var accetabel ville jeg nok bruge LVM til at lave et snapshot som jeg
> derefter kunne køre fsck på for at rydde op i inden jeg lavede mit
> dump.

Nu har jeg lige siddet og leget lidt med LVM-snapshots og alle de
snapshots jeg har fået lavet har filsystemet være helt konsistent og
været markeret som clean. Det havde jeg ikke forventet, så jeg prøvede
endda at lave et snapshot mens der blev kørt Bonnie, det gav samme
fine resultat.

Det er vel fordi jeg bruger ext3?

--
Kim Hansen | |\ _,,,---,,_ | Det er ikke
Vadgårdsvej 3, 2.tv. | /,`.-´` -. ;:-. | Jeopardy.
2860 Søborg | |,4- ) )-,_. ,\ ( `'-' | Svar _efter_
Tlf: 39 56 24 37 | '---''(_/--' `-'\_) | spørgsmålet.

---

Kim Hansen wrote:
>
> Nu har jeg lige siddet og leget lidt med LVM-snapshots og alle de
> snapshots jeg har fået lavet har filsystemet være helt konsistent og
> været markeret som clean. Det havde jeg ikke forventet, så jeg prøvede
> endda at lave et snapshot mens der blev kørt Bonnie, det gav samme
> fine resultat.

Jeg synes det lyder underligt. Hvis filsystemet har været
mountet read/write burde det ikke kunne fremstå som clean
uanset hvad LVM finder på at gøre.

>
> Det er vel fordi jeg bruger ext3?

Jeg mener stadig det burde fremstå som dirty og med en
journal, der skal flushes. Men fsck burde kunne undværes.

--
Kasper Dupont

---

Kasper Dupont <kasperd@daimi.au.dk> writes:

> Kim Hansen wrote:
> >
> > Nu har jeg lige siddet og leget lidt med LVM-snapshots og alle de
> > snapshots jeg har fået lavet har filsystemet være helt konsistent og
> > været markeret som clean. Det havde jeg ikke forventet, så jeg prøvede
> > endda at lave et snapshot mens der blev kørt Bonnie, det gav samme
> > fine resultat.
>
> Jeg synes det lyder underligt. Hvis filsystemet har været
> mountet read/write burde det ikke kunne fremstå som clean
> uanset hvad LVM finder på at gøre.
>
> >
> > Det er vel fordi jeg bruger ext3?
>
> Jeg mener stadig det burde fremstå som dirty og med en
> journal, der skal flushes. Men fsck burde kunne undværes.

Ja, det troede jeg også, men nu har jeg lige kigger med tune2fs på
forskellige filsystemer, og det er ret konsekvent at ext3 er clean
selvom det er mountet. Mens ext2 stadig opfører sig som jeg gik og
forventede.

--
Kim Hansen | |\ _,,,---,,_ | Det er ikke
Vadgårdsvej 3, 2.tv. | /,`.-´` -. ;:-. | Jeopardy.
2860 Søborg | |,4- ) )-,_. ,\ ( `'-' | Svar _efter_
Tlf: 39 56 24 37 | '---''(_/--' `-'\_) | spørgsmålet.

---

Leonard uttered:
> Ja, så kommer der en linie frem:
>
> ro root=LABEL=/ hdc=ide-scsi rhgb
>
> Men når jeg kigger på /proc/ i Filhåndtering står der:
>
> cmdline 0 B Tomt dokument

De "filer" der ligger i /proc er ikke rigtige filer, men
kernel-processer.

--
-- [ kristian ] --------------------------------------------------------
--------------- [if( you->toppost() ) { killfilter->append( you ); }] --
--

---

Kristian Thy wrote:
>
> Leonard uttered:
> > Ja, så kommer der en linie frem:
> >
> > ro root=LABEL=/ hdc=ide-scsi rhgb
> >
> > Men når jeg kigger på /proc/ i Filhåndtering står der:
> >
> > cmdline 0 B Tomt dokument
>
> De "filer" der ligger i /proc er ikke rigtige filer, men
> kernel-processer.

Det er nu ikke helt rigtigt. Det er pseudofiler, hvis
indhold bliver genereret af kernen, når du læser dem.
Men det er kun de directories, hvis navn er et process
ID, der har noget med processer at gøre.

--
Kasper Dupont

---

Kasper Dupont uttered:
> Kristian Thy wrote:
>> De "filer" der ligger i /proc er ikke rigtige filer, men
>> kernel-processer.
>
> Det er nu ikke helt rigtigt. Det er pseudofiler, hvis
> indhold bliver genereret af kernen, når du læser dem.
> Men det er kun de directories, hvis navn er et process
> ID, der har noget med processer at gøre.

Tak for præciseringen.

--
-- [ kristian ] --------------------------------------------------------
--------------- [if( you->toppost() ) { killfilter->append( you ); }] --
--

---

Kasper Dupont <kasperd@daimi.au.dk> wrote:

> Jeg kører selv med et 289GB ext3 filsystem under FC1,
> og det har ikke givet mig nogen problemer. Et stort
> filsystem er kun et problem hvis der opstår nogle
> inkonsistenser, som fsck ikke lige kan håndtere,
> eller hvis du finder ud af, at du hellere vil køre med
> et andet filsystem.

Du har så ikke prøvet at fsck'e et ~500GB ext3 filsystem?

--
Allan Joergensen

"Does this count as a date?"

---

Allan Joergensen wrote:
>
> Du har så ikke prøvet at fsck'e et ~500GB ext3 filsystem?

Næh, det har jeg ikke. Giver det nogen særlige problemer
(ud over at det tager lang tid)?

--
Kasper Dupont

---

Kasper Dupont <kasperd@daimi.au.dk> wrote:

>> Du har så ikke prøvet at fsck'e et ~500GB ext3 filsystem?
> Næh, det har jeg ikke. Giver det nogen særlige problemer
> (ud over at det tager lang tid)?

På et produktionssystem er det et problem. Jeg har også tidligere været
modstander af reiserfs fordi det har smadret filsystemer på
produktionsmaskiner, men det var med kernel 2.2. Jeg er blevet omvendt
efter at jeg var i stand til at ryde omkring 90% af de data der
forsvandt på en 160GB disk efter jeg smadrede det med parted. Hos min
nuværende arbejdsgiver kører vi reiserfs på alle produktionssystemer og
det spiller.

mvh
--
Allan Joergensen

"It sounds like you're cutting a diamond." McCoy to Spock

---

Allan Joergensen wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> wrote:
>
> >> Du har så ikke prøvet at fsck'e et ~500GB ext3 filsystem?
> > Næh, det har jeg ikke. Giver det nogen særlige problemer
> > (ud over at det tager lang tid)?
>
> På et produktionssystem er det et problem. Jeg har også tidligere været
> modstander af reiserfs fordi det har smadret filsystemer på
> produktionsmaskiner, men det var med kernel 2.2.

Jeg har aldrig prøvet reiserfs før version 2.4.16 eller
deromkring.

Under en 2.4 kerne har jeg fået smadret et reiserfs
filsystem så meget, at det ikke kunne repareres igen.
Der var et directory med nogle filer, som godt nok
kunne ses, men som ikke kunne tilgås på nogen måde,
selv stat kaldet fejlede.

Efter anvendelse af resierfsck kunne filsystemet end
ikke mountes.

--
Kasper Dupont

---

Kasper Dupont <kasperd@daimi.au.dk> wrote:

>Jeg plejer at bruge fdisk
>til at partitionere disken.

# fdisk /dev/hdb
Kunne ikke åbne /dev/hdb

Hvad gør jeg så?
Harddisken kan ses i bios og er master på sekundær ide.

--
med venlig hilsen
Leonard - http://leonard.dk/

---

Leonard <nospam@invalid.invalid> wrote:

> Kunne ikke åbne /dev/hdb
> Harddisken kan ses i bios og er master på sekundær ide.

/dev/hdc

--
Allan Joergensen

"How are we doing?" "Same as always" "That bad, huh?"

---

Leonard <nospam@invalid.invalid> writes:

> Kasper Dupont <kasperd@daimi.au.dk> wrote:
>
> >Jeg plejer at bruge fdisk
> >til at partitionere disken.
>
> # fdisk /dev/hdb
> Kunne ikke åbne /dev/hdb
>
> Hvad gør jeg så?
> Harddisken kan ses i bios og er master på sekundær ide.

Så bliver den vist til /dev/hdc, hdb er slaven på den primære. Check
dine bootmeddelelser for at være helt sikker. ('dmesg' eller 'cat
/var/log/boot.log' hvis det ikke er alt for længe side at du sidst har
bootet)

--
O__ ---- Peter Dalgaard Blegdamsvej 3
c/ /'_ --- Dept. of Biostatistics 2200 Cph. N
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907

---

Leonard wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> wrote:
>
> >Jeg plejer at bruge fdisk
> >til at partitionere disken.
>
> # fdisk /dev/hdb
> Kunne ikke åbne /dev/hdb
>
> Hvad gør jeg så?
> Harddisken kan ses i bios og er master på sekundær ide.

hdb er primær slave. hdc er sekundær master.

--
Kasper Dupont

---

Leonard wrote:
> Jeg har sat en ny harddisk i min server der kører Fedora Core 1.
> Hvordan formaterer jeg og monterer den?
> Er der noget med at det er smart at have swap på en anden disk end den
> der bootes på og som systemet ligger på?
> Hvordan ændres det?
>
Hej Leonard

Det er altid en god ide at swapdisken ligger på en anden fysisk harddisk
end systemet. Det gælder faktisk både Unix, Windows og andre systemer.
Det betyder "forenklet" at operativsystemet overlader det til
harddiskcontrolleren at skrive til to diske på samme tid.
En generel god regel som både gælder Unix/Linux såvel som Windows at
swapdisken skal være ca 2 gange størrelsen af RAM, så med en hukommelse
på f.eks 512 MB bør swapdisken være mindst 1 GB.

Med bedste hilsener Mikael

---

Mikael L wrote:
>
> En generel god regel som både gælder Unix/Linux såvel som Windows at
> swapdisken skal være ca 2 gange størrelsen af RAM, så med en hukommelse
> på f.eks 512 MB bør swapdisken være mindst 1 GB.

Men bemærk at på 32 bits kerner er der en grænse på 2GB
pr. swap fil/partition. Man kan så vidt jeg husker have
op til 16 af dem, hvilket betyder maksimalt 32GB swap.

Personligt plejer jeg at lave swap væsentligt større,
så jeg ikke risikerer at løbe tør for swap. Men når swap
forbrug når op på to gange RAM, så kan man altså også
godt mærke det på performance.

Hvis man har mange data på tmpfs filsystemer kan man
godt få brug for væsentlig mere swap uden at man har
noget performance problem.

--
Kasper Dupont

---

Kasper Dupont <kasperd@daimi.au.dk> writes:

> Personligt plejer jeg at lave swap væsentligt større,
> så jeg ikke risikerer at løbe tør for swap. Men når swap
> forbrug når op på to gange RAM, så kan man altså også
> godt mærke det på performance.

Det viser jo bare at behov er forskellige. På min hjemmemaskine har
jeg 1.5 Gb RAM, og jeg er simpelthen holdt op med at køre med
swappartitioner da det umiddelbart ikke giver nogen fordel[1]. Til
Knoppix kopierer jeg endda hele CD'en ind, også uden swap.

Programmer der ikke kan være indenfor hukommelsen var alligevel løbet
løbsk og trængte til at få kniven. Ved at undlade swap undgår man at
maskinen går i knæ fordi disken kværner rundt[2].

tmpfs har jeg kun brugt under Solaris. Det er en fiks opfindelse.


[1] Jeg skrev en 200 siders opgave med mange billeder i LaTeX med
Emacs og Acrobat som previewer på en 32 Mb maskine. Der var swap
meget rart.

[2] Jeg læste engang om en i tidernes morgen der kunne kompilere sin
kerne på sin maskine, _hvis_ han tilføjede swap på en floppy. Det tog
en weekend[3]-

[3] Det kan dog ikke slå ham der ville bruge det uendelige bånd på en
Turingmaskine til swap.
--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus

---

Thorbjoern Ravn Andersen wrote:
>
> Det viser jo bare at behov er forskellige. På min hjemmemaskine har
> jeg 1.5 Gb RAM, og jeg er simpelthen holdt op med at køre med
> swappartitioner da det umiddelbart ikke giver nogen fordel[1].

Jeg ville nok heller ikke bruge ret meget swap, hvis jeg
havde en maskine med så meget RAM.

> Til Knoppix kopierer jeg endda hele CD'en ind, også uden swap.

Hvilket filsystem kopierer du så ind på? Det bedste valg
er nok tmpfs (eller ramfs). Med alle andre filsystemer vil
systemet få brug for at lave to kopier af memory mappede
filer, hvilket blandt andet omfatter alle executables og
libraries. Hvis du har nogle små filer, der aldrig skal
memory mappes vil det slack som 4KB allocering give være
spildt, i så fald ville reiserfs nok være et bedre valg.
I øvrigt bør en CD distribution efter min mening sigte
efter at være brugbar uden swap.

>
> Programmer der ikke kan være indenfor hukommelsen var alligevel løbet
> løbsk og trængte til at få kniven.

Hvordan sikrer du dig, at det er det rigtige program, der dør.

> Ved at undlade swap undgår man at
> maskinen går i knæ fordi disken kværner rundt[2].

Det kan der være noget om. Dog skal man lige bemærke, at man
kan stadig opleve at executables og libraries bliver fjernet
fra RAM. Det betyder i værste fald, at en maskine kan blive
langsommere uden swap, end den ville være med swap.

> tmpfs har jeg kun brugt under Solaris. Det er en fiks opfindelse.

Men hvor praktisk er det uden swap? Det har naturligvis sine
anvendelsesmuligheder, men jeg synes bare ikke det er nær så
brugbart som hvis man kunne swappe.

>
> [2] Jeg læste engang om en i tidernes morgen der kunne kompilere sin
> kerne på sin maskine, _hvis_ han tilføjede swap på en floppy. Det tog
> en weekend[3]-

Det lyder umiddelbart lidt underligt. Hvor havde han sit
filsystem? Lå filsystemet i RAM, så havde det nok været
bedre at lægge filsystemet på floppy og så bruge RAM som
RAM. Lå filsystemet på HD, så havde det nok været bedre at
bruge HD plads som swap også. (Men der var måske engang hvor
man ikke kunne swappe til en fil?)

I øvrigt kan swap bestemt være brugbart i situationer. Jeg
har i mit cron.daily dir et job, der kræver meget RAM. At
kunne swappe mozilla ud om natten er absolut nødvendigt for
at det cron job kan køres.

>
> [3] Det kan dog ikke slå ham der ville bruge det uendelige bånd på en
> Turingmaskine til swap.

Jeg går ud fra at det var en joke, en turingmaskine (TM) er
i hvert fald kun beregnet til teori, ikke til praksis. Jeg
ville personligt hellere have en random access maskine (RAM).

--
Kasper Dupont

---

Kasper Dupont <kasperd@daimi.au.dk> writes:

> > Til Knoppix kopierer jeg endda hele CD'en ind, også uden swap.
>
> Hvilket filsystem kopierer du så ind på? Det bedste valg

Det har jeg ikke fået til at virke - jeg kopierer bare CD'en til RAM
med et passende flag. Tager et par minutter under opstart, og kører
bedårende herefter.

> I øvrigt bør en CD distribution efter min mening sigte
> efter at være brugbar uden swap.

Jada. Men den må gerne kunne bruge de swappartitioner der faktisk er.

Med hensynt il brugbarhed er Knoppix rent subjektivt hurtigere til at
cykle rundt på cd'en end fx Ubuntu. Jeg tror Knopper har brugt tid på
at undersøge hvordan filerne skal ligge.
>
> > Programmer der ikke kan være indenfor hukommelsen var alligevel løbet
> > løbsk og trængte til at få kniven.
>
> Hvordan sikrer du dig, at det er det rigtige program, der dør.

Top giver al den nødvendige information.

> > tmpfs har jeg kun brugt under Solaris. Det er en fiks opfindelse.
>
> Men hvor praktisk er det uden swap? Det har naturligvis sine
> anvendelsesmuligheder, men jeg synes bare ikke det er nær så
> brugbart som hvis man kunne swappe.

Det er skam fint. Du tager fra den samlede mængde virtuelle
hukommelse. Uden swap er det bare fra ram. Under Solaris ville jeg
dog nok ikke lave nummeret.

>
> >
> > [2] Jeg læste engang om en i tidernes morgen der kunne kompilere sin
> > kerne på sin maskine, _hvis_ han tilføjede swap på en floppy. Det tog
> > en weekend[3]-
>
> Det lyder umiddelbart lidt underligt. Hvor havde han sit
> filsystem? Lå filsystemet i RAM, så havde det nok været
> bedre at lægge filsystemet på floppy og så bruge RAM som
> RAM. Lå filsystemet på HD, så havde det nok været bedre at
> bruge HD plads som swap også. (Men der var måske engang hvor
> man ikke kunne swappe til en fil?)

Maskinen var så lille at ram+swap ikke var nok til gcc til en særlig
krævende fil i kernen. Som jeg husker det.

> > [3] Det kan dog ikke slå ham der ville bruge det uendelige bånd på en
> > Turingmaskine til swap.
>
> Jeg går ud fra at det var en joke, en turingmaskine (TM) er
> i hvert fald kun beregnet til teori, ikke til praksis. Jeg
> ville personligt hellere have en random access maskine (RAM).

Ser man bort fra tidsforbruget er det jo det samme.

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus

---

Thorbjoern Ravn Andersen wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> writes:
>
> > > Til Knoppix kopierer jeg endda hele CD'en ind, også uden swap.
> >
> > Hvilket filsystem kopierer du så ind på? Det bedste valg
>
> Det har jeg ikke fået til at virke - jeg kopierer bare CD'en til RAM
> med et passende flag. Tager et par minutter under opstart, og kører
> bedårende herefter.

OK, det er selvfølgelig også det nemmeste.

>
> > I øvrigt bør en CD distribution efter min mening sigte
> > efter at være brugbar uden swap.
>
> Jada. Men den må gerne kunne bruge de swappartitioner der faktisk er.

Muligheden skal selvfølgelig være til stede.
Jeg synes dog ikke den skal skrive til harddisken
uden at spørge først.

> >
> > > Programmer der ikke kan være indenfor hukommelsen var alligevel løbet
> > > løbsk og trængte til at få kniven.
> >
> > Hvordan sikrer du dig, at det er det rigtige program, der dør.
>
> Top giver al den nødvendige information.

Vil det sige, at du altid kan nå at slå den
problematiske process ihjel før kernen selv
begynder at slå processer ned?

> >
> > Jeg går ud fra at det var en joke, en turingmaskine (TM) er
> > i hvert fald kun beregnet til teori, ikke til praksis. Jeg
> > ville personligt hellere have en random access maskine (RAM).
>
> Ser man bort fra tidsforbruget er det jo det samme.

Udover at en RAM er hurtigere end en TM, så
er det også nemmere at programere en RAM end
en TM. Men hvis man ikke bekymrer sig om
polynomielle faktorer, så gør det naturligvis
ingen forskel.

--
Kasper Dupont

---

Kasper Dupont <kasperd@daimi.au.dk> writes:

> Vil det sige, at du altid kan nå at slå den
> problematiske process ihjel før kernen selv
> begynder at slå processer ned?

Næh, jeg kommer meget sjældent i dén situation. Det er som regel den
der kværnen rundt i swap der rammer mig.

Hvis så linuxkernen bare kunne hitte ud af at være responsiv
alligevel, så gik det nok alligevel. Det kan den svjv bar eikke.

> > > Jeg går ud fra at det var en joke, en turingmaskine (TM) er
> > > i hvert fald kun beregnet til teori, ikke til praksis. Jeg
> > > ville personligt hellere have en random access maskine (RAM).
> >
> > Ser man bort fra tidsforbruget er det jo det samme.
>
> Udover at en RAM er hurtigere end en TM, så
> er det også nemmere at programere en RAM end
> en TM. Men hvis man ikke bekymrer sig om
> polynomielle faktorer, så gør det naturligvis
> ingen forskel.

Næh - de kan som bekendt det samme (hvis man ser bort fra
tidsforbruget).

Det er også bare teoretisk tidsfordriv.

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus

---

Thorbjoern Ravn Andersen wrote:
>
> Hvis så linuxkernen bare kunne hitte ud af at være responsiv
> alligevel, så gik det nok alligevel.

Kernen er bestemt hurtig til at reagere, også selvom den
er i gang med at swappe helt vildt. Et program der har brug
for at tilgå disken vil til gengæld i sagens natur være
langsomt. Og mange programmer skal nok have nogle sider
swappet ind før de kan komme videre.

--
Kasper Dupont

---

Kasper Dupont wrote:

> Kernen er bestemt hurtig til at reagere, også selvom den
> er i gang med at swappe helt vildt. Et program der har brug
> for at tilgå disken vil til gengæld i sagens natur være
> langsomt. Og mange programmer skal nok have nogle sider
> swappet ind før de kan komme videre.

Vil kernen så kunne finde udaf at splitte SWAP ud i 2 SWAP partitioner/filer
på hver sin fysiske disk, eller vil den bruge den ene først, og så forsæte
med den anden?

--
Med venlig hilsen

Ivar Madsen

---

Ivar Madsen wrote:
>
> Kasper Dupont wrote:
>
> > Kernen er bestemt hurtig til at reagere, også selvom den
> > er i gang med at swappe helt vildt. Et program der har brug
> > for at tilgå disken vil til gengæld i sagens natur være
> > langsomt. Og mange programmer skal nok have nogle sider
> > swappet ind før de kan komme videre.
>
> Vil kernen så kunne finde udaf at splitte SWAP ud i 2 SWAP partitioner/filer
> på hver sin fysiske disk, eller vil den bruge den ene først, og så forsæte
> med den anden?

Som jeg allerede har nævnt et sted i tråden, så afhænger
det af de prioriteter du sætter på partitionerne. Hvis
de har forskellig prioriteter startes med den højeste,
og først når den er fyldt fortsættes til den næste.

Hvis to swap partitioner har samme prioritet vil kernen
som udgangspunkt forsøge at lægge lige meget på dem.
(Jeg ved ikke om den også gør det, hvis de har forskellig
størrelse, eller om den så lægger mest på den største).

Den præcise algoritme for fordeling til to swap partitioner
med samme prioritet, kender jeg ikke. Det simpleste ville
være at bare kigge på hvor meget plads, der er i brug på
hver. En mere soffistikeret algoritme ville også tage
højde for den aktuelle brug af den fysiske disk, og undgå
at lægge mange data på en travl disk.

Når data skal swappes ind igen kan de naturligvis kun
læses fra den disk, de ligger på. Der ville under nogen
omstændigheder være en pointe i at swappe de samme data
ud til mere end en disk. Men det tror jeg ikke Linux kan.

Hvis man har swap på flere harddiske skal man også være
opmærksom på, at hvis blot en af dem fejler, så kan det
i praksis betyde at alle programmer går ned. Skal et
program bruge en side, som er swappet ned på en fejlet
disk, så er kernen nødt til at slå programmet ned.

--
Kasper Dupont

---

Kasper Dupont wrote:
> Thorbjoern Ravn Andersen wrote:
>
>>Kasper Dupont <kasperd@daimi.au.dk> writes:
>>
>SNIP<
>
>>>Jeg går ud fra at det var en joke, en turingmaskine (TM) er
>>>i hvert fald kun beregnet til teori, ikke til praksis. Jeg
>>>ville personligt hellere have en random access maskine (RAM).
>>
>>Ser man bort fra tidsforbruget er det jo det samme.
>
>
> Udover at en RAM er hurtigere end en TM, så
> er det også nemmere at programere en RAM end
> en TM. Men hvis man ikke bekymrer sig om
> polynomielle faktorer, så gør det naturligvis
> ingen forskel.
>

Er der nogen der lige kan give en kort forklaring på turingmaskine er?

eller evt. et link til en besrkivelse (dansk, engelsk eller tysk)

m.v.h. Mikael

---

Mikael Hansen <mikael.hansen@DELETE.post.cybercity.dk> writes:

> Er der nogen der lige kan give en kort forklaring på turingmaskine er?

http://en.wikipedia.org/wiki/Turing_machine

En strengt minimalistisk teoretisk konstruktion som er lige så
beregningsmæssigt stærk som alle andre computere. Varianten
"Universiel Turing Maskine" kan emulere en anden Turingmaskine og
udføre algoritmer.

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus