---

Hejsa

Jeg har en maskine med en 5-6 uger gammel installation af FC2, og den er
ved at drive mig til vanvid. Den er simpelthen blevet så sn** langsom, at
jeg er ved at få pip.

Jeg har på det sidste lavet en del med store filer som er blevet kopieret
over på maskinen, pakket ud, flyttet rundt på og slettet igen - kan
sådanne manøvrer gøre filsystemet (ext3) træt? Maskinen står næsten
konstant og babber på harddisken (og det er en bærbar med en forholdsvis
sløv disk, så det er _ikke_ sjovt).

.... og kan bittorrent have noget med sagen at gøre (jeg mener at have
læst noget i den dur engang)?

Hvad kan jeg i givet fald gøre ved problemet?

--
Mvh.
/Thomas

---

Thomas Lindgaard wrote:

> Jeg har på det sidste lavet en del med store filer som er blevet kopieret
> over på maskinen, pakket ud, flyttet rundt på og slettet igen - kan
> sådanne manøvrer gøre filsystemet (ext3) træt? Maskinen står næsten
> konstant og babber på harddisken (og det er en bærbar med en forholdsvis
> sløv disk, så det er _ikke_ sjovt).
>
> ... og kan bittorrent have noget med sagen at gøre (jeg mener at have
> læst noget i den dur engang)?

Hvis du bruger bittorrent, så skal du regne med at din harddisk er aktiv
hele tiden, da der (når du downloader) skal skrives og (når du uploader)
læses data fra harddisken.

Desuden kan bittorrent også belaste systemet, hvis du har gang i nogle
store filer og at der er mange brugere om denne fil.

--
Anders Lund - anders@andersonline.dk

---

On Fri, 23 Jul 2004 20:26:00 +0200, Anders Lund wrote:

> Hvis du bruger bittorrent, så skal du regne med at din harddisk er aktiv
> hele tiden, da der (når du downloader) skal skrives og (når du uploader)
> læses data fra harddisken.
>
> Desuden kan bittorrent også belaste systemet, hvis du har gang i nogle
> store filer og at der er mange brugere om denne fil.

Det er klart - men det er ikke det der giver mig problemer lige nu (har
ikke nogen bittorrent kørende nu).

Men jeg kunne forestille mig at bittorrent sammen med en masse
filoperationer har fået fragmenteret min disk (jeg var lige nede på 250
KB fri plads, så der har ikke været meget at gøre med
oprydningsmæssigt).

Findes der noget defragmenteringshalløj til Linux - eller er jeg bedst
tjent med simpelthen at reinstallere og så være sødere ved maskinen i
fremtiden?

--
Mvh.
/Thomas

---

Thomas Lindgaard wrote in
<news:pan.2004.07.23.21.35.50.595338@it-snedkeren.BLACK_HOLE.dk>:

> Findes der noget defragmenteringshalløj til Linux - eller er jeg
> bedst tjent med simpelthen at reinstallere og så være sødere ved
> maskinen i fremtiden?

Hvis du tilfældigvis har en ekstra disk, kan du overveje en fattig-
mands defragmentering. Det går i al sin enkelthed ud på at kopiere
(flytte) al data fra den ene disk over på den anden (hvorved de bliver
lagt i pæn orden), og evt. tilbage igen.

Mht. bittorrent, så kommer det meget an på klienten, og opsætningen af
samme, hvor meget fragmentering der skabes. Hvis du har en klient der
er opsat til at skrive hver fil efterhånden som den hentes
(incremental), evt. fordi klienten ikke kan andet, så er der basis for
rigtig meget fragmentering. Specielt hvis du henter flere filer af
gangen. Og /specielt/ hvis du er ved at løbe tør for plads.

Andre klienter (for eksempel Azureus) kan konfigureres til at allokere
og zero-fill hele filens størrelse fra starten, hvorved der næsten
ingen fragmentering opstår.

--
Niels Callesøe - dk pfy @work
pfy[at]nntp.dk - http://www.pcpower.dk/disclaimer.php

Learn Postfix; live Postfix; love Postfix.

---

Thomas Lindgaard <thomas@it-snedkeren.BLACK_HOLE.dk> writes:

>Findes der noget defragmenteringshalløj til Linux - eller er jeg bedst
>tjent med simpelthen at reinstallere og så være sødere ved maskinen i
>fremtiden?

Defragmentering giver ikke mening på ext2 filsystemet. Selv hvis du
kunne defragmentere det, ville filsystemet af sig selv ende på samme
fragmenteringsniveau kort tid efter. Det gør ikke noget - det er
designet til at arbejde på den måde, og read/write-ahead gør, at det
næsten ikke kan betale sig at tænke på det.

ext2 er ikke designet til at give maksimal performance til én proces.
Det er designet til at læse/skrive mange filer samtidig, fordi Linux
er et multitasking operativsystem. Der er en masse optimering bygget
ind i det, der faktisk vil betyde, at defragmentering vil gøre den
overordnerede performance væsentligt ringere.

Ikke engang bittorrent-scenariet vil betyde noget nævneværdigt på
ext2. Der er taget højde for den type "trafik" ved at bruge
"preallocation", der spænder over (mindst) et readahead-fragment.

MSDOS/VFAT er det modsatte: her skal filsystemet typisk servicere én
bruger, der næppe laver ret mange diskkrævende samtidigt. Derfor giver
det mening at sørge for, at filerne er ubrudte.

(ext3 virker nøjagtigt på samme måde som ext2 i denne sammenhæng)

Mvh.
   Klaus.

---

On Fri, 23 Jul 2004 21:59:50 +0000, Klaus Ellegaard wrote:

> Defragmentering giver ikke mening på ext2 filsystemet. Selv hvis du
> kunne defragmentere det, ville filsystemet af sig selv ende på samme
> fragmenteringsniveau kort tid efter.

Det vil sige at filsystemet hele tiden arbejder i baggrunden på at lægge
filerne pænt? Så det eneste jeg skal gøre for at det kan lykkes er at
sørge for at der er noget fri plads på disken?

--
Mvh.
/Thomas

---

Thomas Lindgaard <thomas@it-snedkeren.BLACK_HOLE.dk> writes:

>> Defragmentering giver ikke mening på ext2 filsystemet. Selv hvis du
>> kunne defragmentere det, ville filsystemet af sig selv ende på samme
>> fragmenteringsniveau kort tid efter.

>Det vil sige at filsystemet hele tiden arbejder i baggrunden på at lægge
>filerne pænt?

Nej, de ligger pænt fra starten.

Hvis du vil have et filsystem, der er optimeret til single-user-
performance, skal du skifte til VFAT. ext2 supporter ikke at være
hurtigt for andet end "ægte multitasking"-systemer. Og det er netop
årsagen til, at defragmentering er en meget dårlig ide.

>Så det eneste jeg skal gøre for at det kan lykkes er at
>sørge for at der er noget fri plads på disken?

Man kan optimere diskaccess på to måder:

1) Sørge for at en fil læses hurtigst muligt. Det kræver, at filen
ligger ubrudt på disken, og at ingen andre processer rører disken,
mens filen læses. Defragmentering er påkrævet for at dette virker.

2) Sørge for at disksystemet leverer så meget data som muligt til
det samlede system. Det kræver ikke defragmentering, men det kræver
til gengæld, at filsystemet har en yderst intelligent måde at lægge
filerne på allerede fra starten af.

ext2 understøtter kun nummer to ovenfor. VFAT (gamle Windows'er)
understøtter kun den første model.

Det betyder, at der ikke skal defragmenteres på ext2 - ja, det vil
faktisk gøre performance meget værre, hvis det blev defragmenteret.

Men det betyder også, at Windows vil vinde stort, hvis du laver en
hastighedstest, der går ud på at læse en 500 MB fil hurtigt.

Til gengæld vinder ext2 stort, hvis du beder om at få læst 10.000
filer 50 KB på én gang.


Ergo er konklusionen: du kan intet gøre for at forbedre performance
på et ext2-filsystem. Det er desinget til altid at levere den mest
optimale performance for et TRAVLT MULTITASKING-system.

Det giver ingen mening at sammenligne VFAT og ext2. De er godtnok
begge designet til at gemme filer på, men ligesom både en sportsvogn
og et krydstogtskib begge er designet til persontransport, kan man
ikke sammenligne dem direkte. Deres respektive designfilosofier (og
den opgave de skal løse) er alt for forskellige.

Mvh.
   Klaus.

---

Thomas Lindgaard wrote:
>
> Men jeg kunne forestille mig at bittorrent sammen med en masse
> filoperationer har fået fragmenteret min disk (jeg var lige nede på 250
> KB fri plads, så der har ikke været meget at gøre med
> oprydningsmæssigt).

Er du sikker? ext2 og ext3 reserverer som default 5%
af diskpladsen, så denne kun kan bruges af root. Det
gøres bla. for at undgå den fragmentering, som let
opstår når disken er næsten helt fuld.

>
> Findes der noget defragmenteringshalløj til Linux - eller er jeg bedst
> tjent med simpelthen at reinstallere og så være sødere ved maskinen i
> fremtiden?

Du kan starte med at undersøge hvor fragmenteret
disken er. Der findes defragmenteringsværktøjer til
ext2, men jeg er ikke sikker på at de er testet så
godt, at jeg turde stole på dem.

Men inden du begynder at gøre mere ved det bør du
nok undersøge, om der evt. kunne være nogle cron job,
der er årsag til stor aktivitet på disken.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
I'd rather be a hammer than a nail.

---

Kasper Dupont <remove.invalid@nospam.lir.dk.invalid> writes:

>Er du sikker? ext2 og ext3 reserverer som default 5%
>af diskpladsen, så denne kun kan bruges af root. Det
>gøres bla. for at undgå den fragmentering, som let
>opstår når disken er næsten helt fuld.

Der foretages aldrig oprydning på ext2 nogensinde - og der er
ikke indbygget automatisk defragmentering i ext2. Det er slet
og ret ikke nødvendigt.

Du tænker nok på BSDs ufs, der omkring de 5-10% skifter intern
optimeringsstrategi?

Mvh.
   Klaus.

---

Den Sat, 24 Jul 2004 10:07:43 +0000 (UTC) skrev Klaus Ellegaard:
> Kasper Dupont <remove.invalid@nospam.lir.dk.invalid> writes:
>
>>Er du sikker? ext2 og ext3 reserverer som default 5%
>>af diskpladsen, så denne kun kan bruges af root. Det
>>gøres bla. for at undgå den fragmentering, som let
>>opstår når disken er næsten helt fuld.
>
> Der foretages aldrig oprydning på ext2 nogensinde - og der er
> ikke indbygget automatisk defragmentering i ext2. Det er slet
> og ret ikke nødvendigt.
>
> Du tænker nok på BSDs ufs, der omkring de 5-10% skifter intern
> optimeringsstrategi?

Nej, den er god nok. 5% af diskpladsen er som default reserveret til
root, af to årsager:

1. Hvis disken bliver fyldt helt op, kan filsystemet ikke længere vælge
det optimale sted at placere data. Og da der ikke senere ryddes op, vil
disse data blive ved med at ligge et uoptimalt sted (indtil filen evt
slettes).

2. Når disken er fyldt, kan brugerne ikke lave noget, måske ikke engang
logge ind. Og så får man fat i administratoren...

login: root
Password:
sh: No space left on device
login:

Derfor sikrer man at der er lidt fri plads reserveret til root, i det
mindste på / og /var - men mke2fs kan ikke se forskel, så den reserverer
konsekvent 5%

Det kan slås fra med tune2fs.

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

---

Kent Friis wrote:
>
> Den Sat, 24 Jul 2004 10:07:43 +0000 (UTC) skrev Klaus Ellegaard:
> > Kasper Dupont <remove.invalid@nospam.lir.dk.invalid> writes:
> >
> >>Er du sikker? ext2 og ext3 reserverer som default 5%
> >>af diskpladsen, så denne kun kan bruges af root. Det
> >>gøres bla. for at undgå den fragmentering, som let
> >>opstår når disken er næsten helt fuld.
> >
> > Der foretages aldrig oprydning på ext2 nogensinde - og der er
> > ikke indbygget automatisk defragmentering i ext2. Det er slet
> > og ret ikke nødvendigt.

Nej, men havde man ikke reserveret de 5%, ville det blive nødvendigt.

Jeg kan ikke lige sige om man virkelig har brug for at reservere så
meget. Det har været 5% siden dengang harddiskene var mindre end
10GB. Jeg kan godt forestille mig, at mindre end 5% ville kunne
gøre det, med den størrelse diske har i dag. Men jeg har dog ingen
tal til at underbygge den formodning.

>
> login: root
> Password:
> sh: No space left on device
> login:

Så galt har jeg alligevel aldrig oplevet, at det er gået. Jeg har
været ude for, at man ikke kunne starte X.

>
> Derfor sikrer man at der er lidt fri plads reserveret til root, i det
> mindste på / og /var - men mke2fs kan ikke se forskel, så den reserverer
> konsekvent 5%
>
> Det kan slås fra med tune2fs.

Alternativt kan man nøjes med at ændre det fra 5% til f.eks. 1%.
Man kan også angive en bruger som skal have lov til at bruge
pladsen.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
I'd rather be a hammer than a nail.

---

Den Sat, 24 Jul 2004 15:08:34 +0200 skrev Kasper Dupont:
> Kent Friis wrote:
>>
>> login: root
>> Password:
>> sh: No space left on device
>> login:
>
> Så galt har jeg alligevel aldrig oplevet, at det er gået. Jeg har
> været ude for, at man ikke kunne starte X.

Det er bare et spørgsmål hvad root's .profile indeholder.

(Af samme grund har root på min maskine ikke nogen .profile - selv en
simple 'tset' kan gøre det svært at logge ind, hvis man har fået nuked
terminfo).

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

---

Kent Friis wrote:
>
> Det er bare et spørgsmål hvad root's .profile indeholder.
>
> (Af samme grund har root på min maskine ikke nogen .profile - selv en
> simple 'tset' kan gøre det svært at logge ind, hvis man har fået nuked
> terminfo).

Der kunne jo egentlig være en pointe i at have to
forskellige root accounts med hver sit brugrnavn og
home directory. En til almindelig administration og
en til når man virkelig har dummet sig.

Så vidt jeg husker bliver der altid kørt noget fra
/etc selvom man ikke har nogen .filer i sit home
directory. Så /root uden .filer er heller ikke
sikret mod den slags fejl.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
I'd rather be a hammer than a nail.

---

Den Sat, 24 Jul 2004 22:52:37 +0200 skrev Kasper Dupont:
> Kent Friis wrote:
>>
>> Det er bare et spørgsmål hvad root's .profile indeholder.
>>
>> (Af samme grund har root på min maskine ikke nogen .profile - selv en
>> simple 'tset' kan gøre det svært at logge ind, hvis man har fået nuked
>> terminfo).
>
> Der kunne jo egentlig være en pointe i at have to
> forskellige root accounts med hver sit brugrnavn og
> home directory. En til almindelig administration og
> en til når man virkelig har dummet sig.

Det kan være en fordel.

> Så vidt jeg husker bliver der altid kørt noget fra
> /etc selvom man ikke har nogen .filer i sit home
> directory. Så /root uden .filer er heller ikke
> sikret mod den slags fejl.

Måske:

emergency:x:0:0:root:/:/bin/bash -noprofile

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

---

Kasper Dupont <remove.invalid@nospam.lir.dk.invalid> writes:

>> > Der foretages aldrig oprydning på ext2 nogensinde - og der er
>> > ikke indbygget automatisk defragmentering i ext2. Det er slet
>> > og ret ikke nødvendigt.

>Nej, men havde man ikke reserveret de 5%, ville det blive nødvendigt.

Det er ikke korrekt.

Den situation vil kun opstå for de filer, der skal skrives, og hvor
der ikke er plads til 16 konsekutive fragmenter. Det vil kun meget
sjældent ske - netop på grund af ext2fs' preallocation. Fyldt
filsystem eller ej.

>Jeg kan ikke lige sige om man virkelig har brug for at reservere så
>meget. Det har været 5% siden dengang harddiskene var mindre end
>10GB. Jeg kan godt forestille mig, at mindre end 5% ville kunne
>gøre det, med den størrelse diske har i dag. Men jeg har dog ingen
>tal til at underbygge den formodning.

Selvom du sætter reservationen ned til én bit på en 50000 TB volume,
vil det stadig ikke ændre på, at filer meget sjældent fragmenteres.

Selvfølgelig vil det ske til sidst, men det vil være forsvindende
få filer, og på grund af ext2fs' design med sektor-vandring, vil det
ikke betyde nævneværdig hastighedsnedsættelse alligevel.

Om noget kan man sige, at ext2 vil performe MEGET ringe på et system,
der overhovedet ikke er fragmenteret.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
>
> Den situation vil kun opstå for de filer, der skal skrives, og hvor
> der ikke er plads til 16 konsekutive fragmenter. Det vil kun meget
> sjældent ske - netop på grund af ext2fs' preallocation. Fyldt
> filsystem eller ej.

Det kommer i høj grad an på adgangsmønstret. Man kan
nemt konstruere et adgangsmønster der resulterer i 100%
fragmentering hvis ikke der reserveres diskplads eller
defragmenteres på runtime.

Og det vil være tilfældet uanset hvor godt filsystemet
er designet. Men det er ikke trivielt at gennemskue,
præcis hvor galt det kan gå med hhv. 1% og 5% reserveret.

>
> Selvom du sætter reservationen ned til én bit på en 50000 TB volume,
> vil det stadig ikke ændre på, at filer meget sjældent fragmenteres.

Det kan jo slet ikke lade sig gøre.

>
> Selvfølgelig vil det ske til sidst, men det vil være forsvindende
> få filer, og på grund af ext2fs' design med sektor-vandring, vil det
> ikke betyde nævneværdig hastighedsnedsættelse alligevel.

Hvad mener du lige præcis med sektor-vandring?

>
> Om noget kan man sige, at ext2 vil performe MEGET ringe på et system,
> der overhovedet ikke er fragmenteret.

Det tvivler jeg kraftigt på. Men før det kan testes
skal man have en meget præcis definition af fragmentering.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
I'd rather be a hammer than a nail.

---

Kasper Dupont <remove.invalid@nospam.lir.dk.invalid> writes:

>Det kommer i høj grad an på adgangsmønstret. Man kan
>nemt konstruere et adgangsmønster der resulterer i 100%
>fragmentering hvis ikke der reserveres diskplads eller
>defragmenteres på runtime.

Jada, ligesom man kan vise, at Unix er totalt ubrugeligt i forhold
til Windows. Det kræver bare de rette forudsætninger for forsøget.

>Og det vil være tilfældet uanset hvor godt filsystemet
>er designet. Men det er ikke trivielt at gennemskue,
>præcis hvor galt det kan gå med hhv. 1% og 5% reserveret.

Det går lige galt i alle praktiske sammenhænge.


>> Selvfølgelig vil det ske til sidst, men det vil være forsvindende
>> få filer, og på grund af ext2fs' design med sektor-vandring, vil det
>> ikke betyde nævneværdig hastighedsnedsættelse alligevel.

>Hvad mener du lige præcis med sektor-vandring?

ext2's read-algoritme er baseret på, at den vandrer op gennem
sektorerne og læser i den rækkefølge, brugbare data bliver
tilgængelige set fra det samlede access-behov. Den søger altså
ikke efter data til læsning af én fil, medmindre resten af OS'et
står stille.

>> Om noget kan man sige, at ext2 vil performe MEGET ringe på et system,
>> der overhovedet ikke er fragmenteret.

>Det tvivler jeg kraftigt på. Men før det kan testes
>skal man have en meget præcis definition af fragmentering.

....og du skal læse lidt op på ext2s algoritmer

Det er klart, at en læsning, der er baseret på forudsætninger, som
ext2 ikke er designet til at håndtere, vil gå langsomt og være alt
andet end optimalt. Heri indgår bl.a. defragmenteret disk. Det er
ikke en ønskelig situation set med ext2's øjne, og i forhold til
ext2's opgave (system-wide performance i et kraftigt multitasking-
miljø) vil det performe helt tosset.

Uanset hvordan man så definerer fragmentering.

Pointen er netop, at fragmentering aldrig vil opstå i første omgang,
før pre-allocation af 16 sammenhængende fragmenter fejler. For at
lave et filsystem, der kan emulere det, skal du virkelig være meget
kreativ. Det vil kræve millioner af små filer og nogle enkelte store
filer, der slettes i den rigtige rækkefølge.

Selvfølgelig kan det lade sig gøre, men jeg vil i den sammenhæng ikke
skyde skylden for fragmenteringen på ext2: snarere den totalt clueless
programmør, der har bragt filsystemet i den situation.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
>
> ext2's read-algoritme er baseret på, at den vandrer op gennem
> sektorerne og læser i den rækkefølge, brugbare data bliver
> tilgængelige set fra det samlede access-behov. Den søger altså
> ikke efter data til læsning af én fil, medmindre resten af OS'et
> står stille.

Det lyder som en beskrivelse af elevatoralgoritmen,
som mig bekendt ligger på et lag under filsystemet.

>
> Selvfølgelig kan det lade sig gøre, men jeg vil i den sammenhæng ikke
> skyde skylden for fragmenteringen på ext2: snarere den totalt clueless
> programmør, der har bragt filsystemet i den situation.

Jeg er ikke enig i, hvor skylden skal placeres. Hvis
der er gode grunde til, at applikationen foretager
skrivninger på den måde, så skal filsystemet kunne
håndtere det.

Man skal designe sin kode, så den opfører sig
fornuftigt på et worst case input. Hvis et enkelt
program, der laver nogle uheldige skrivninger, kan
give performance problemer på langt sigt, så er
filsystemet ikke fornuftigt designet.

Det kan godt være at defragmentering på runtime er
nødvendigt hvis et filsystem skal håndtere vilkårlige
adgangsmønstre. Det er lidt for kompliceret til at
jeg lige kan gennemskue det uden at regne ret
grundigt på det.

Det er da rigtigt nok, at de adgangsmønstre hvor jeg
har skabt ekstrem fragmentering på f.eks. FAT er
konstrueret til formålet. Men man kan ikke afvise,
at der ikke også findes normale adgangsmønstre, som
vil resultere i lignende problemer. Så vidt jeg
husker er bittorrent tit blevet nævnt som et
eksempel.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
I'd rather be a hammer than a nail.

---

Kasper Dupont <remove.invalid@nospam.lir.dk.invalid> writes:

>Man skal designe sin kode, så den opfører sig
>fornuftigt på et worst case input. Hvis et enkelt
>program, der laver nogle uheldige skrivninger, kan
>give performance problemer på langt sigt, så er
>filsystemet ikke fornuftigt designet.

Det kan man ikke: hvad hvis jeg vil skrive 250 milliarder filer
à 470 bytes i timen og have 100 års data liggende på én volume?

Kan man deraf konkludere, at ext2fs er totalt håbløst designet,
når den "ikke engang kan det"?

Nej, man må vende bøtten om: ext2 er designet til at være så
hurtigt som muligt i et travlt multitasking-miljø. Hvis det ikke
er dét, man har tænkt sig at bruge filsystemet til, så fejler
man ved at bruge det.

Ellers kan man jo også sige, at mainframes er dårligt designet:
det er umuligt at spille Hitman på dem.

>Det kan godt være at defragmentering på runtime er
>nødvendigt hvis et filsystem skal håndtere vilkårlige
>adgangsmønstre. Det er lidt for kompliceret til at
>jeg lige kan gennemskue det uden at regne ret
>grundigt på det.

Du behøver ikke regne på det. ext2 regnes for noget nær det
bedste kompromis, når snakken går på det, det er designet til.

Men dermed bestemt ikke sagt, at det er bedst til alt. Det er
der intet, der er.

Mvh.
   Klaus.

---

On 2004-08-01, Klaus Ellegaard <klausellegaard@msn.com> wrote:

> Men dermed bestemt ikke sagt, at det er bedst til alt. Det er
> der intet, der er.

Vise ord! Der er intet der er sort/hvidt her i verden.

<flameproof suit>

emacs vs. vi
linux vs. windows
minix vs. linux
freebsd vs. linux
Cox vs. Torvalds
Amd vs. Intel
Nvidia vs. ATI
.....

</flameproof suit>

Thomas

---

Klaus Ellegaard wrote:
>
> Kasper Dupont <remove.invalid@nospam.lir.dk.invalid> writes:
>
> >Man skal designe sin kode, så den opfører sig
> >fornuftigt på et worst case input. Hvis et enkelt
> >program, der laver nogle uheldige skrivninger, kan
> >give performance problemer på langt sigt, så er
> >filsystemet ikke fornuftigt designet.
>
> Det kan man ikke: hvad hvis jeg vil skrive 250 milliarder filer
> à 470 bytes i timen og have 100 års data liggende på én volume?

Det du foreslår kan man ikke af den simple grund at der
ikke er plads nok på disken. Og det kan da godt være at
systemet bliver lidt sløvt hvis du starter et program,
der prøver på at gøre det. Men når programmet stoppes
igen skal systemet igen kører med en fornuftig performance.
Det ville være uacceptabelt hvis systemet kører med
nedsat performance i flere år herefter, blot fordi du
engang har kørt et tåbeligt program.

>
> Men dermed bestemt ikke sagt, at det er bedst til alt. Det er
> der intet, der er.

Jeg vil formode man kan designe et filsystem, der har en
fornuftig amortiseret kompleksitet på alle de operationer
man typisk foretager.

Du kan altid optimere lidt på filsystemet, så det er
bedre egnet til en bestemt anvendelse. Men hvis andre
operationer bliver sløvet ned med en faktor 1000000, så
vil jeg kalde det et dårligt valg.

Selvfølgelig kan du ikke designe et filsystem, der altid
fungerer optimalt. Men muligvis kan du sikre dig, at du
altid er indenfor en konstant faktor fra det optimale.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
I'd rather be a hammer than a nail.

---

Kent Friis <nospam@nospam.invalid> writes:

>1. Hvis disken bliver fyldt helt op, kan filsystemet ikke længere vælge
>det optimale sted at placere data. Og da der ikke senere ryddes op, vil
>disse data blive ved med at ligge et uoptimalt sted (indtil filen evt
>slettes).

Det er jo småtingsafdelingen. På et veludlagt filsystem vil det som
oftest højst være nogle få megabytes, der vil blive lagt uoptimalt.
Det vil i praksis give forsinkelser, der end ikke kan måles.

>2. Når disken er fyldt, kan brugerne ikke lave noget, måske ikke engang
>logge ind. Og så får man fat i administratoren...

>login: root
>Password:
>sh: No space left on device
>login:

Det afhænger meget af din variant og den profile. Her går det fint.

Mvh.
   Klaus.

---

Den Wed, 28 Jul 2004 09:00:47 +0000 (UTC) skrev Klaus Ellegaard:
> Kent Friis <nospam@nospam.invalid> writes:
>
>>2. Når disken er fyldt, kan brugerne ikke lave noget, måske ikke engang
>>logge ind. Og så får man fat i administratoren...
>
>>login: root
>>Password:
>>sh: No space left on device
>>login:
>
> Det afhænger meget af din variant og den profile. Her går det fint.

Fuldstændig korrekt, derfor ordet "måske"

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

---

Thomas Lindgaard wrote:

> Hejsa
>
> Jeg har en maskine med en 5-6 uger gammel installation af FC2, og den er
> ved at drive mig til vanvid. Den er simpelthen blevet så sn** langsom, at
> jeg er ved at få pip.
>
> Jeg har på det sidste lavet en del med store filer som er blevet kopieret
> over på maskinen, pakket ud, flyttet rundt på og slettet igen - kan
> sådanne manøvrer gøre filsystemet (ext3) træt? Maskinen står næsten
> konstant og babber på harddisken (og det er en bærbar med en forholdsvis
> sløv disk, så det er _ikke_ sjovt).

Ext2 og 3 er gode til selv at sørge for at dataene ikke bliver så
fragmenterede som på f.eks. fat32, hvis du ellers har en rimelig mængde fri
plads.

> ... og kan bittorrent have noget med sagen at gøre (jeg mener at have
> læst noget i den dur engang)?
>
> Hvad kan jeg i givet fald gøre ved problemet?
>

Når bittorrent går igang med at hente en fil, allokerer den så hele filens
størrelse eller lader den filen 'gro' efterhånden som den henter data?
For hvis det sidste er tilfældet, og du henter flere filer samtidigt, så
bliver din disk temmelig fragmenteret.

--
Lasse Jensen [fafler at linuxmail dot org]