---

Aloha!

Selvom filsystemer som ReiserFS og Ext3 er meget resistente overfor
defragmentering er de vel ikke helt immune!

Findes der nogen defragmenteringsprogrammer (Især rettet imod serverbrug)
til Linux .... enten kommercielle eller Opensource ???

En ydmyg tak tpå denne kolde morgen!

--

Live long and prosper...
________________________________________
Peter Jespersen, Member of TeamOS/2 DK
flywheel@illogical.dk
http://www.illogical.dk
Computers run on faith, not electrons.

---

Den Fri, 15 Feb 2002 09:08:05 +0100 skrev Peter Jespersen:
>Aloha!
>
>Selvom filsystemer som ReiserFS og Ext3 er meget resistente overfor
>defragmentering er de vel ikke helt immune!

Nej, hvis du kører i længere tid med en 99% fyldt disk, og løbende
sletter små filer for at blive ved med at have en smule plads, så er
de faktisk tvunget til at fragmentere data.

>Findes der nogen defragmenteringsprogrammer (Især rettet imod serverbrug)
>til Linux .... enten kommercielle eller Opensource ???

Det findes, ja. Men det er ikke noget der bliver brugt, og dermed er
det ikke særlig grundigt testet, så det anbefales at lave en backup før
man går igang... og den mest effektive defragmentering er faktisk at
lave en backup, rydde disken, og læse backup'en ind igen, så det kan man
vel lige så godt gøre når man har lavet backup'en.

Men inden du går så vidt, så prøv lige at køre en tvungen fsck - på ext3
fortæller den hvor fragmenteret disken er (kig efter "non-contiguous") -
jeg har aldrig set en disk der var mere end 20% fragmenteret.

Mvh
Kent
--
Running Windows on a Pentium is like having a brand new Porsche but only
be able to drive backwards with the handbrake on.
(Unknown source)

---

Kent Friis wrote:

> Den Fri, 15 Feb 2002 09:08:05 +0100 skrev Peter Jespersen:
>>Aloha!
>>
>>Selvom filsystemer som ReiserFS og Ext3 er meget resistente overfor
>>defragmentering er de vel ikke helt immune!
>
> Nej, hvis du kører i længere tid med en 99% fyldt disk, og løbende
> sletter små filer for at blive ved med at have en smule plads, så er
> de faktisk tvunget til at fragmentere data.

Det er også en skidt ide. Jeg tror ikke, der findes filsystemer, der ikke
lider under at være fyldt mere end 90% eller 95%. Det skulle da lige være
iso9660, cramfs og andre read-only filsystemer. Prisen ved at fylde en disk
til randen på den måde er simpelthen for stor...

>>Findes der nogen defragmenteringsprogrammer (Især rettet imod serverbrug)
>>til Linux .... enten kommercielle eller Opensource ???
>
> Det findes, ja. Men det er ikke noget der bliver brugt, og dermed er
> det ikke særlig grundigt testet, så det anbefales at lave en backup før
> man går igang... og den mest effektive defragmentering er faktisk at
> lave en backup, rydde disken, og læse backup'en ind igen, så det kan man
> vel lige så godt gøre når man har lavet backup'en.

Svjv ikke til reiserfs. Der findes vistnok til ext2 (og dermed el også
ext3)

> Men inden du går så vidt, så prøv lige at køre en tvungen fsck - på ext3
> fortæller den hvor fragmenteret disken er (kig efter "non-contiguous") -
> jeg har aldrig set en disk der var mere end 20% fragmenteret.

20% var meget - jeg har vist aldrig set noget over 5%

Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
If you don't receive an answer, then it either indicates that the bug is
too obvious or too difficult.
-- Manfred Spraul
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

Den Fri, 15 Feb 2002 10:25:45 +0100 skrev Rasmus Bøg Hansen:
>Kent Friis wrote:
>
>> Den Fri, 15 Feb 2002 09:08:05 +0100 skrev Peter Jespersen:
>>>Aloha!
>>>
>>>Selvom filsystemer som ReiserFS og Ext3 er meget resistente overfor
>>>defragmentering er de vel ikke helt immune!
>>
>> Nej, hvis du kører i længere tid med en 99% fyldt disk, og løbende
>> sletter små filer for at blive ved med at have en smule plads, så er
>> de faktisk tvunget til at fragmentere data.
>
>Det er også en skidt ide. Jeg tror ikke, der findes filsystemer, der ikke
>lider under at være fyldt mere end 90% eller 95%. Det skulle da lige være
>iso9660, cramfs og andre read-only filsystemer. Prisen ved at fylde en disk
>til randen på den måde er simpelthen for stor...

Der findes SVJV filsystemer der automatisk defragmenterer on-the-fly.
Men ok, de lider stadig, det er bare CPU-belastningen der stiger i
stedet.

>>>Findes der nogen defragmenteringsprogrammer (Især rettet imod serverbrug)
>>>til Linux .... enten kommercielle eller Opensource ???
>>
>> Det findes, ja. Men det er ikke noget der bliver brugt, og dermed er
>> det ikke særlig grundigt testet, så det anbefales at lave en backup før
>> man går igang... og den mest effektive defragmentering er faktisk at
>> lave en backup, rydde disken, og læse backup'en ind igen, så det kan man
>> vel lige så godt gøre når man har lavet backup'en.
>
>Svjv ikke til reiserfs. Der findes vistnok til ext2 (og dermed el også
>ext3)

Du har sikkert ret - jeg snakkede om ext2/3. Har aldrig beskæftiget mig
med reiserfs.

>> Men inden du går så vidt, så prøv lige at køre en tvungen fsck - på ext3
>> fortæller den hvor fragmenteret disken er (kig efter "non-contiguous") -
>> jeg har aldrig set en disk der var mere end 20% fragmenteret.
>
>20% var meget - jeg har vist aldrig set noget over 5%

Ved nærmere eftersyn har jeg faktisk en 16MB partition der er 38.5%
fragmenteret. De mere normale partitioner ligger dog nede omkring 5%

Mvh
Kent
--
What was your username?
<Clicketyclick> - B.O.F.H.

---

Kent Friis wrote:

>>Det er også en skidt ide. Jeg tror ikke, der findes filsystemer, der ikke
>>lider under at være fyldt mere end 90% eller 95%. Det skulle da lige være
>>iso9660, cramfs og andre read-only filsystemer. Prisen ved at fylde en
>>disk til randen på den måde er simpelthen for stor...
>
> Der findes SVJV filsystemer der automatisk defragmenterer on-the-fly.
> Men ok, de lider stadig, det er bare CPU-belastningen der stiger i
> stedet.

Det er vist rigtigt. Men det er jo heller ikke rart at bruge CPU-kræfter,
hvis man har bedre ting at bruge dem til...

>>20% var meget - jeg har vist aldrig set noget over 5%
>
> Ved nærmere eftersyn har jeg faktisk en 16MB partition der er 38.5%
> fragmenteret. De mere normale partitioner ligger dog nede omkring 5%

Når jeg nu tænker efter, var min gamle /boot-partition også ret
fragmenteret - men den havde også fået kernen skiftet ud adskillige gange
og var typisk fyldt op med 6Mb ud af 8... Men ydelse på /boot betyder nu
ikke så meget for mig

Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
Life is that property, which a being will lose as a result of falling
out of a cold and mysterious cave 30 miles above ground level.
- HitchHikers Guide to the Galaxy, Douglas Adams
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

Den Fri, 15 Feb 2002 10:41:33 +0100 skrev Rasmus Bøg Hansen:
>Kent Friis wrote:
>
>> Ved nærmere eftersyn har jeg faktisk en 16MB partition der er 38.5%
>> fragmenteret. De mere normale partitioner ligger dog nede omkring 5%
>
>Når jeg nu tænker efter, var min gamle /boot-partition også ret
>fragmenteret - men den havde også fået kernen skiftet ud adskillige gange
>og var typisk fyldt op med 6Mb ud af 8... Men ydelse på /boot betyder nu
>ikke så meget for mig

Det påvirker da ikke ydelsen på /boot mærkbart - de par cylindre den
partition dækker, det kan ikke kræve meget bevægelse af læse/skrive-
hovedet. Og så er det hele selvfølgelig i cachen inden man overhovedet
opdager noget.

Mvh
Kent
--
The revolution has just begun.

---

On Fri, 15 Feb 2002 08:24:29 +0000 (UTC), kfr@fleggaard.dk (Kent
Friis) wrote:

>>Selvom filsystemer som ReiserFS og Ext3 er meget resistente overfor
>>defragmentering er de vel ikke helt immune!
>Nej, hvis du kører i længere tid med en 99% fyldt disk, og løbende
>sletter små filer for at blive ved med at have en smule plads, så er
>de faktisk tvunget til at fragmentere data.

Kunne man ikke med fordel, til server brug, lave et filsystem, som ved
oprettelse af filer af bestemte typer allokerte x antal MB til filen,
så der er afset plads til udvidelser?

---

Ivar Madsen wrote:

> Kunne man ikke med fordel, til server brug, lave et filsystem, som ved
> oprettelse af filer af bestemte typer allokerte x antal MB til filen,
> så der er afset plads til udvidelser?

Det findes på mainframes, og det er vildt bøvlet at administrere.

Databaser (f.eks Oracle) gør noget lignende ved at allokerer plads på
forhånd (ved at fylde ud med nuller), så der er en god chance for at
data kommer til at ligge i sammenhængende områder på disken.

-Claus

---

On Sat, 16 Feb 2002 15:36:54 +0100, Claus Rasmussen
<clr@cc-consult.dk> wrote:


>> Kunne man ikke med fordel, til server brug, lave et filsystem, som ved
>> oprettelse af filer af bestemte typer allokerte x antal MB til filen,
>> så der er afset plads til udvidelser?
>Det findes på mainframes,

Det anede mig, at jeg ikke skulle opfinde den dybe tarlerken, efter
computeren har eksisteret i så mange år,,,

>og det er vildt bøvlet at administrere.

Hvorfor, er det ikke automatiseret godtnok?

>Databaser (f.eks Oracle) gør noget lignende ved at allokerer plads på
>forhånd (ved at fylde ud med nuller), så der er en god chance for at
>data kommer til at ligge i sammenhængende områder på disken.

Det kunne også være effektivt med newsserver, hvor der jo også
heletiden kommer nye data, og de ælste data bliver smidt væk, så
forleden en fil der bestod af flere tusinde dele,,,

---

Ivar Madsen wrote:

> Hvorfor, er det ikke automatiseret godtnok?

He, he... Det er skam lavet: Det hedder automatisk defragmentering og
er implementeret i f.eks ext2


Forestil dig, at du har din fine plan for, hvordan pladsen på disken
skal fordeles mellem de forskellige applikationer, der bruger den
aktuelle disk.

Så sker der bare det, at brugernes adfærdsmønster ændrer sig, og
lige pludseligt er der ikke nok plads på den oprindelige disk.

Så du skal finde en ny disk, og navnlig en disk, hvor den ekstra trafik
ikke kommer til at genere andre vigtige applikationer. Men allerførst
skal du jo selvfølgelig afgøre om det opståede problem er vedvarende
eller bare en forbigående "spike". Du skal selvfølgelig også undersøge
om problemet ikke bare skyldes en applikation, der er gået amok og
som har spammet disken.

Når du så har afsluttet alle dine undersøgelser og har besluttet dig
for at problemet er reelt og vedvarende skal du have flyttet data. I
et produktionsmiljø handler det om en hel del mere end bare at fyre
en 'mv gammel-sti/data ny-sti'. Du skal have brugernes applikationer
stoppet, sikre dig at der ikke kører en backup, lave dokumentation
(så andre driftsmedarbejdere ved hvor filerne ligger), teste at der
ikke ligger en hardcodet path i koden osv. osv. osv i een uendelighed.

Du /kan/ simpelthen ikke automatisere det. Der er aalt for mange
mennesker involveret og alt for mange ricisi, til at du tør lade en
dæmon om at gøre alt det.

-Claus

---

On Sat, 16 Feb 2002 17:50:04 +0100,
Claus Rasmussen <clr@cc-consult.dk> wrote:
> Du skal selvfølgelig også undersøge
> om problemet ikke bare skyldes en applikation, der er gået amok og
> som har spammet disken.

Det har jeg prøvet, hold kæft hvor kunne man lige pludselig blive træt
af at det pludseligt var muligt at lave filer på mere end 2GB. Kan man
egentlig sætte en max. filstørrelse et eller andet sted?

--
Like a rat in a maze Anders Bo Rasmussen mailto:fuzz01@spamfilter.dk
The path before me lies Frimestervej 42 1.tv http://www.fuzz.dk
And the pattern never alters 2400 Kbh. NV
Until the rat dies.

---

Anders Bo Rasmussen wrote:

> Det har jeg prøvet, hold kæft hvor kunne man lige pludselig blive træt
> af at det pludseligt var muligt at lave filer på mere end 2GB. Kan man
> egentlig sætte en max. filstørrelse et eller andet sted?

Morsomt

Først hører man brok i årevis fordi nogle enkelte high-end installationer
har behov for at lave gigantstore filer. Så kommer der omsider en feature
i linux som løser problemet, hvorefter man opdager, at alle de almindelige
brugere i mellemtiden har fået så store diske, at de nu ønsker sig tilbage
til de "gode gamle dage".

Utaknemmelige skarn !

-Claus

---

On Sat, 16 Feb 2002 17:50:04 +0100, Claus Rasmussen
<clr@cc-consult.dk> wrote:

>He, he... Det er skam lavet: Det hedder automatisk defragmentering og
>er implementeret i f.eks ext2

Du svare i øst, hvor jeg spørger i vest,,,

|>> Kunne man ikke med fordel, til server brug, lave et filsystem, som ved
|>> oprettelse af filer af bestemte typer allokerte x antal MB til filen,
|>> så der er afset plads til udvidelser?
|>Det findes på mainframes,

|Det anede mig, at jeg ikke skulle opfinde den dybe tarlerken, efter
|computeren har eksisteret i så mange år,,,

|>og det er vildt bøvlet at administrere.

|Hvorfor, er det ikke automatiseret godtnok?

Det er alså muligheden for at nye filer får afsat plads på disken i et
samlet fragment du siger ikke er til at administere, og jeg så spørger
om det skyldes at det ikke er automatiskeret godtnok, jeg forstiller
mig, at man sætter op, at filer der ender på .endelse får afsat x MB
når den oprettes på disken.

---

Den Sat, 16 Feb 2002 19:23:00 +0100 skrev Ivar Madsen:
>On Sat, 16 Feb 2002 17:50:04 +0100, Claus Rasmussen
><clr@cc-consult.dk> wrote:
>
>>He, he... Det er skam lavet: Det hedder automatisk defragmentering og
>>er implementeret i f.eks ext2
>
>Du svare i øst, hvor jeg spørger i vest,,,
>
>|>> Kunne man ikke med fordel, til server brug, lave et filsystem, som ved
>|>> oprettelse af filer af bestemte typer allokerte x antal MB til filen,
>|>> så der er afset plads til udvidelser?
>|>Det findes på mainframes,
>
>|Det anede mig, at jeg ikke skulle opfinde den dybe tarlerken, efter
>|computeren har eksisteret i så mange år,,,
>
>|>og det er vildt bøvlet at administrere.
>
>|Hvorfor, er det ikke automatiseret godtnok?
>
>Det er alså muligheden for at nye filer får afsat plads på disken i et
>samlet fragment du siger ikke er til at administere, og jeg så spørger
>om det skyldes at det ikke er automatiskeret godtnok, jeg forstiller
>mig, at man sætter op, at filer der ender på .endelse får afsat x MB
>når den oprettes på disken.

og så skulle man til at navngive filer efter hvor store man forventer
de bliver?

ansøgning.2kb
mitbillede.1mb
pr0narchive.100mb

Eller tænker du på windows, hvor filer skal have en bestemt endelse,
for at systemet kan finde ud af at håndtere dem?

Mvh
Kent
--
Which one is faster - Lotus Notes or Lotus Esprit?

---

On Sat, 16 Feb 2002 18:28:08 +0000 (UTC), kfr@fleggaard.dk (Kent
Friis) wrote:

>og så skulle man til at navngive filer efter hvor store man forventer
>de bliver?
>ansøgning.2kb
>mitbillede.1mb
>pr0narchive.100mb

Nej, jeg tænker ikke på klientmaskiner, men på server, mest på
newsserver, hvor det kunne være rat at have afsat en fast størelse på
datafilerne. Newsserver er meget hårde ved diskene, hver gang der
bliver skrevet et indlæg, så fare det rundt på alverdens newsserver,
og bliver tilføjet, når næste indlæg i gruppen bliver skrevet, så
vare det rundt, og bliver tilfjøjet. På et tidspunkt bliver gamle
indlæg så slettet. Det gør at sådan en datafil hurtigt bliver
fragmateret i flere tusinde fragmenter. Der ville det hjælpe hvis
systemmet kunne holde styr på det, så filen havde en fast min.
størelse, og når der blev slettet, så blev data rykket fram i filen, i
perioder hvor disken ikke blev brugt.

>Eller tænker du på windows, hvor filer skal have en bestemt endelse,
>for at systemet kan finde ud af at håndtere dem?

Jeg tænker ikke på noget bestemt OS, men dette er en UNIX gruppe, så
et filsystem der kan bruges under UNIX af en eller anden afart vil nok
være hvad jeg forventede svar på,,,

---

Den Sun, 17 Feb 2002 01:54:25 +0100 skrev Ivar Madsen:
>On Sat, 16 Feb 2002 18:28:08 +0000 (UTC), kfr@fleggaard.dk (Kent
>Friis) wrote:
>
>>og så skulle man til at navngive filer efter hvor store man forventer
>>de bliver?
>>ansøgning.2kb
>>mitbillede.1mb
>>pr0narchive.100mb
>
>Nej, jeg tænker ikke på klientmaskiner, men på server, mest på
>newsserver, hvor det kunne være rat at have afsat en fast størelse på
>datafilerne. Newsserver er meget hårde ved diskene, hver gang der
>bliver skrevet et indlæg, så fare det rundt på alverdens newsserver,
>og bliver tilføjet, når næste indlæg i gruppen bliver skrevet, så
>vare det rundt, og bliver tilfjøjet. På et tidspunkt bliver gamle
>indlæg så slettet. Det gør at sådan en datafil hurtigt bliver
>fragmateret i flere tusinde fragmenter. Der ville det hjælpe hvis
>systemmet kunne holde styr på det, så filen havde en fast min.
>størelse, og når der blev slettet, så blev data rykket fram i filen, i
>perioder hvor disken ikke blev brugt.

Forstår jeg det rigtigt, at din newsserver bruger en stor fil til alle
indlæg? Så burde newsserveren selv holde styr på sin datafil - specielt
det du nævner med at rykke data frem i filen, hvis OS'et gjorde dette,
ville newsserveren jo ikke længere vide hvor den skulle finde tingene.

Som jeg læser dit indlæg, så er det slet ikke filsystemet der bliver
fragmenteret, men derimod indholdet af en enkelt fil.

Mvh
Kent
--
Object orientation: the idea, that humans find it easier to understand
"you.car.engine.start" than "start your car engine".

---

On Sun, 17 Feb 2002 08:01:24 +0000 (UTC), kfr@fleggaard.dk (Kent
Friis) wrote:

>Forstår jeg det rigtigt, at din newsserver bruger en stor fil til alle
>indlæg?

Ja, en fil pr. gruppe.

>Så burde newsserveren selv holde styr på sin datafil - specielt
>det du nævner med at rykke data frem i filen, hvis OS'et gjorde dette,
>ville newsserveren jo ikke længere vide hvor den skulle finde tingene.

Hmm, serveren beder jo OS'et om filen, men jeg kan godt se at den så
ikke vil vide hvor i filen den skal søge hvad, hvis OS'et ændre på
filens indhold,,,

>Som jeg læser dit indlæg, så er det slet ikke filsystemet der bliver
>fragmenteret, men derimod indholdet af en enkelt fil.

Indholdet er filen bliver vel ikke fragmenteret, det er selve filen
der bliver det,,,

BTW det skal måske lige nævnes at den omtalte server køre på win98 /
XP, men prencippet i det er jo det samme uanset filsystem,,,

---

Den Sun, 17 Feb 2002 10:05:36 +0100 skrev Ivar Madsen:
>On Sun, 17 Feb 2002 08:01:24 +0000 (UTC), kfr@fleggaard.dk (Kent
>Friis) wrote:
>
>>Forstår jeg det rigtigt, at din newsserver bruger en stor fil til alle
>>indlæg?
>
>Ja, en fil pr. gruppe.

ok

>>Så burde newsserveren selv holde styr på sin datafil - specielt
>>det du nævner med at rykke data frem i filen, hvis OS'et gjorde dette,
>>ville newsserveren jo ikke længere vide hvor den skulle finde tingene.
>
>Hmm, serveren beder jo OS'et om filen, men jeg kan godt se at den så
>ikke vil vide hvor i filen den skal søge hvad, hvis OS'et ændre på
>filens indhold,,,

OS'et kan heller ikke se hvilken del af filens indhold der er "indhold",
og hvilken del der er "slettet".

>>Som jeg læser dit indlæg, så er det slet ikke filsystemet der bliver
>>fragmenteret, men derimod indholdet af en enkelt fil.
>
>Indholdet er filen bliver vel ikke fragmenteret, det er selve filen
>der bliver det,,,

Hvis et indlæg ligger spredt som 10 stumper i filen, så er det indholdet
der er fragmenteret. Hvis filen ligger spredt som 100 stumper på
filsystemet, så er det filen/filsystemet der er fragmenteret. Som jeg
ser det skulle der ikke være nogen grund til at filsystemet bliver
fragmenteret.

>BTW det skal måske lige nævnes at den omtalte server køre på win98 /
>XP, men prencippet i det er jo det samme uanset filsystem,,,

Så længe vi snakker om indholdet at filen, og ikke filens placering i
filsystemet - ja, så er det det samme.

Mvh
Kent
--
Desuden kan jeg ikke se nogen grund til at springe over hvor gærdet er
lavest, når man kan vente på at det alligevel bliver revet ned fordi
der skal bygges en omfartsvej...
- Claus Frørup og Asbjørn Christensen i dk.snak.

---

On Sun, 17 Feb 2002 09:22:51 +0000 (UTC), kfr@fleggaard.dk (Kent
Friis) wrote:

>OS'et kan heller ikke se hvilken del af filens indhold der er "indhold",
>og hvilken del der er "slettet".

Du har ret, jeg ved ikke lige hvad jeg har tænkt på,,,

>>>Som jeg læser dit indlæg, så er det slet ikke filsystemet der bliver
>>>fragmenteret, men derimod indholdet af en enkelt fil.
>>Indholdet er filen bliver vel ikke fragmenteret, det er selve filen
>>der bliver det,,,
>Hvis et indlæg ligger spredt som 10 stumper i filen, så er det indholdet
>der er fragmenteret.

Ja, men jeg kan ikke se, hvorfor serveren skulle gøre det,,,

>Hvis filen ligger spredt som 100 stumper på
>filsystemet, så er det filen/filsystemet der er fragmenteret. Som jeg
>ser det skulle der ikke være nogen grund til at filsystemet bliver
>fragmenteret.

Hvis du skriver til en eksisterende fil, ved at tilfjøe til
slutningen, det gør du 10.000 gange om månenden[1] hvorledes kan du
undgå at den fil vil blive fragmentetet i nogle tusinde stumper, hvis
ikke at Sereveren/OS'et kan gøre noget for at undgå det?

>>BTW det skal måske lige nævnes at den omtalte server køre på win98 /
>>XP, men prencippet i det er jo det samme uanset filsystem,,,
>Så længe vi snakker om indholdet at filen, og ikke filens placering i
>filsystemet - ja, så er det det samme.

Det vil ikke komme bag på mig, om unix's standart filsystem er beder
til at undgå for mange fragmenter, jeg kender ikke så meget til det,
men prencippet med at der et sted på disken er et katalog over hvilke
filer der ligger med start hvor, samt info om hvor det forsætter,
eller måske at der i fragmentet ligger info om hvor der forsættes, går
vel igen på alle filsystemmer, til alle OS'er?
En væsentlig forskæld fra CP/M's system er vel mest at det ikke er et
bestemt område der indeholder info om hvad der ligger hvor, og at når
det område er fuldt, så kan der ikke lægges flere filer, til at
kataloget er mere spredt over disken,,,

[1] på et newssetup, med realtids feed, får du et enkelt indlæg af
gangen, og skriver det på disken inden der gås vider med næste
modtagne indlæg.

---

Den Sun, 17 Feb 2002 12:03:42 +0100 skrev Ivar Madsen:
>On Sun, 17 Feb 2002 09:22:51 +0000 (UTC), kfr@fleggaard.dk (Kent
>Friis) wrote:
>
>>>>Som jeg læser dit indlæg, så er det slet ikke filsystemet der bliver
>>>>fragmenteret, men derimod indholdet af en enkelt fil.
>>>Indholdet er filen bliver vel ikke fragmenteret, det er selve filen
>>>der bliver det,,,
>>Hvis et indlæg ligger spredt som 10 stumper i filen, så er det indholdet
>>der er fragmenteret.
>
>Ja, men jeg kan ikke se, hvorfor serveren skulle gøre det,,,

Klag til programmøren - der må være nogen der har syntes det var smart.

>>Hvis filen ligger spredt som 100 stumper på
>>filsystemet, så er det filen/filsystemet der er fragmenteret. Som jeg
>>ser det skulle der ikke være nogen grund til at filsystemet bliver
>>fragmenteret.
>
>Hvis du skriver til en eksisterende fil, ved at tilfjøe til
>slutningen, det gør du 10.000 gange om månenden[1] hvorledes kan du
>undgå at den fil vil blive fragmentetet i nogle tusinde stumper, hvis
>ikke at Sereveren/OS'et kan gøre noget for at undgå det?

Den fil vil blive meget stor...

Sålænge vi taler om selve filen, og ikke indholdet, kan OS'et gøre
forskellige ting for at undgå at den bliver fragmenteret.

>Det vil ikke komme bag på mig, om unix's standart filsystem er beder
>til at undgå for mange fragmenter, jeg kender ikke så meget til det,
>men prencippet med at der et sted på disken er et katalog over hvilke
>filer der ligger med start hvor, samt info om hvor det forsætter,
>eller måske at der i fragmentet ligger info om hvor der forsættes, går
>vel igen på alle filsystemmer, til alle OS'er?

Alle filsystemer er vel i princippet opbygget på den måde. Og alle
filsystemer kan blive fragmenteret, der er bare forskel på hvor meget
der skal til før at det sker. FAT bliver det helt af sig selv, bare
man bruger systemet, hvorimod fx. ext2 normalt ikke har problemer
med fragmentering, medmindre partitionen er næsten fyldt.

Mvh
Kent
--
Indlæringskurven til Linux er stejl, til tider lodret... Men for katten
hvor er udsigten på toppen dog fantastisk
- Michael G. Vendelbo i dk.snak

---

kfr@fleggaard.dk (Kent Friis) wrote:

>Forstår jeg det rigtigt, at din newsserver bruger en stor fil til alle
>indlæg? Så burde newsserveren selv holde styr på sin datafil - specielt
>det du nævner med at rykke data frem i filen, hvis OS'et gjorde dette,
>ville newsserveren jo ikke længere vide hvor den skulle finde tingene.

Det, Ivar mener, er vel, at OS'et skal sørge for ikke at placere
filerne som perler på en snor. Hvis de lægges med lidt luft imellem,
er der plads til, at de kan vokse et stykke, uden at der opstår
fragmentering. Det burde ikke kunne forårsage konflikter mellem OS og
program.

Hvis man så oven i købet kan opsætte regler for, at bestemte filer
skal have afsat ekstra luft, fordi man ved, at de vil vokse mere end
normalt, kan man endnu bedre undgå fragmentering.

Men jeg aner ikke, hvordan ext2 opfører sig på det punkt. Jeg ved, at
FAT lægger filerne lige efter hinanden, således at hvis flere filer
hele tiden vokser lige så stille, kan de ikke andet end blive voldsomt
defragmenterede.


--
Allan Olesen, Lunderskov

"UNIX er overflødigt." - Lars P. Fischer

---

Allan Olesen <aolesen@post3.tele.dk> wrote:

>Men jeg aner ikke, hvordan ext2 opfører sig på det punkt. Jeg ved, at
>FAT lægger filerne lige efter hinanden, således at hvis flere filer
>hele tiden vokser lige så stille, kan de ikke andet end blive voldsomt
>defragmenterede.

s/defragmenterede/fragmenterede/


--
Allan Olesen, Lunderskov

"UNIX er overflødigt." - Lars P. Fischer

---

Ivar Madsen <news-02-01-02@milli.dk> writes:

> On Sat, 16 Feb 2002 18:28:08 +0000 (UTC), kfr@fleggaard.dk (Kent
> Friis) wrote:
>
> >og så skulle man til at navngive filer efter hvor store man forventer
> >de bliver?
> >ansøgning.2kb
> >mitbillede.1mb
> >pr0narchive.100mb
>
> Nej, jeg tænker ikke på klientmaskiner, men på server, mest på
> newsserver, hvor det kunne være rat at have afsat en fast størelse på
> datafilerne. Newsserver er meget hårde ved diskene, hver gang der
> bliver skrevet et indlæg, så fare det rundt på alverdens newsserver,
> og bliver tilføjet, når næste indlæg i gruppen bliver skrevet, så
> vare det rundt, og bliver tilfjøjet. På et tidspunkt bliver gamle
> indlæg så slettet. Det gør at sådan en datafil hurtigt bliver
> fragmateret i flere tusinde fragmenter. Der ville det hjælpe hvis
> systemmet kunne holde styr på det, så filen havde en fast min.
> størelse, og når der blev slettet, så blev data rykket fram i filen, i
> perioder hvor disken ikke blev brugt.

Har du kigget på CNFS?

http://www.eyrie.org/~eagle/faqs/inn.html#2.2

Så vidt jeg kunne læse mig til (andetsteds) kræver det dog at
styresystemet kan mmap(2)'e block devices.

--
Christian Hemmingsen

---

On 17 Feb 2002 13:28:52 +0100, Christian Hemmingsen
<postmaster@hemmingsen.nospam.kampsax.k-net.dk> wrote:

>Har du kigget på CNFS?

Nej

>http://www.eyrie.org/~eagle/faqs/inn.html#2.2

Har nu kikket på punkt 2.2 og ikke resten af siden.
Det er en måde at gøre det på, omend der, som der også er nævnt, er
ulæmper ved den metode også, men det er da noget der er vær at kikke
på, når jeg kommer så langt med projektet. pt er det sat på vågeplus
pga. mangel på tid

>Så vidt jeg kunne læse mig til (andetsteds) kræver det dog at
>styresystemet kan mmap(2)'e block devices.

OK.

---

Ivar Madsen wrote:

> On Sat, 16 Feb 2002 17:50:04 +0100, Claus Rasmussen
>
>>He, he... Det er skam lavet: Det hedder automatisk defragmentering og
>>er implementeret i f.eks ext2
>
> Du svare i øst, hvor jeg spørger i vest,,,

Nej. Det jeg forklarede, var hvad man skulle igennem for at administrere
sådan et system manuelt. Hvis man automatiserede det på en måde, man ville
spare noget arbejde ved, ville man bare ende med noget, der svarer til
automatisk defragmentering.

De største problemer ved at preallokere plads består i alle de ting, der
ikke kan automatiseres: Underretning af brugere, nedlukning af applika-
tioner (nej, det kan ikke automatiseres), test, planlægning af disk-
allokeringer osv. osv. osv.

Jeg kan fortælle, at jeg har arbejdet hos TDC. I den afdeling, jeg sad i,
var der vel tre mand fuldtidsbeskæftiget med at styre diskpladsen på vores
maskiner - ud af 20 mand.

[...]


> Det er alså muligheden for at nye filer får afsat plads på disken i et
> samlet fragment du siger ikke er til at administere, og jeg så spørger
> om det skyldes at det ikke er automatiskeret godtnok, jeg forstiller
> mig, at man sætter op, at filer der ender på .endelse får afsat x MB
> når den oprettes på disken.

Jamen hvad så når den preallokerede plads slipper op ? Og omvendt: Hvad
hvis du har allokeret for meget plads ? Med mindre du har automatisk
defragmentering, skal du selv til at pille, når det sker. Og det sker
_hele_ tiden, fordi verden forandrer sig.

-Claus

---

On Sun, 17 Feb 2002 05:45:07 +0100, Claus Rasmussen
<clr@cc-consult.dk> wrote:

>Jamen hvad så når den preallokerede plads slipper op ?

Så sllokeres der ekstra plads, måske af halv størelse af gangen, og
man må leve med så at få et ekstra fragment.

>Og omvendt: Hvad
>hvis du har allokeret for meget plads ?

Så har man spild af plads. Det er klart, og man må vudere med sig
selv, om man vil sætte parameterene for højt, og så få spild af
plads, eller om man vil sætte dem således at der er mindre spild af
plads, men at der bliver nogle fragmenter. Derved har du stadig
undgået, som jeg faktisk HAR været ude for, at en fil kommer til at
bestå af 8-9 tusinde fragmenter,,,

>Med mindre du har automatisk
>defragmentering, skal du selv til at pille, når det sker. Og det sker
>_hele_ tiden, fordi verden forandrer sig.

Jeg kunne nu stadig godt ønske mig at kunne sætte mit OS til at
allokere x MB når der oprettes filer af bestemte typer, når pladsen er
opbrugt, så allokeres der ekstra y MB. Hvor x = 2 * y. Når der blev
slettet fra starten af filen, så at dataene blev flyttet ud i starten
af filen.
Og så enten kun på bestemte filtyper, eller til nød på en partition
hvor dataene ligger, og holde .config filer på andre partiotioner.
Eller måske at serverappliktionen selv allokere pladsen til de filer
hvor der er behov for det.
Nu har jeg ikke fået kikket så meget på det, men mit udmilbare indtryk
er at Diablo gør noget i den retning til dens SPOOL.

---

Ivar Madsen <news-02-01-02@milli.dk> writes:

> Jeg kunne nu stadig godt ønske mig at kunne sætte mit OS til at
> allokere x MB når der oprettes filer af bestemte typer, når pladsen er
> opbrugt, så allokeres der ekstra y MB.

Det burde ikke være svært at implementerer, hvis altså man klare sig
med mmap(2).

Man ville nok kunne lave en open/read/close-semantik oven på mmap. Med
en passende SIGBUS-handler er det måske ikke så svært, men nok noget
der mindst ville tage en eftermiddags kodning for at lave en proof of
concept-implementation af.

--
Når folk spørger mig, om jeg er nørd, bliver jeg altid ilde til mode
og svarer lidt undskyldende: "Nej, jeg bruger RedHat".
-- Allan Olesen på dk.edb.system.unix