---

Hejsa!

Jeg har en disk hvorpå der ligger cd 50Gb backupfiler som jeg skal ha
slettet.
Filerne er taget med
   cp -al * `date`
dvs der er ikke kun mange men en ala helvedes masse links til et hav af
filer.

Indtil nu har rm -rf * kørt i halvandet døgn og har fået slettet ca
10% af filerne.

Er der ikke en lettere måde til simplthen at slå /backup ihjel?

"mv /backup /dev/null" virker desværre ikke

På forhånd tak.

/Henning

---

Den Tue, 24 Jan 2006 18:10:50 +0100 skrev Henning Wangerin:
> Hejsa!
>
> Jeg har en disk hvorpå der ligger cd 50Gb backupfiler som jeg skal ha
> slettet.
> Filerne er taget med
>    cp -al * `date`
> dvs der er ikke kun mange men en ala helvedes masse links til et hav af
> filer.
>
> Indtil nu har rm -rf * kørt i halvandet døgn og har fået slettet ca
> 10% af filerne.
>
> Er der ikke en lettere måde til simplthen at slå /backup ihjel?

Det eneste alternativ jeg lige kan se er debugfs, slette directory-
indgangen, og så lade fsck redde tråddene ud - men der er både
risikabelt, og kunne nemt gå hen og tage endnu længere tid.

Risikabelt fordi det bevidst ødelægger konsistensen af filsystemet,
og hvis fsck ikke kan redde tingene, er der ikke nogen måde at
redde det på. Og jeg kunne godt være bange for at den løber tør for
RAM når det er så meget der skal ryddes op i.

Så jeg vil ikke anbefale metoden. Slet ikke. Men det er det der kommer
nærmest hvad jeg forestiller mig du havde i tankerne.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
>
> Den Tue, 24 Jan 2006 18:10:50 +0100 skrev Henning Wangerin:
> >
> > Er der ikke en lettere måde til simplthen at slå /backup ihjel?
>
> Det eneste alternativ jeg lige kan se er debugfs, slette directory-
> indgangen, og så lade fsck redde tråddene ud - men der er både
> risikabelt, og kunne nemt gå hen og tage endnu længere tid.

Jeg tror ikke engang det hjælper. fsck vil jo opdage, at der
er et fuldstændigt konsistent directory helt uden links til,
og så vil den bare oprette et link i /lost+found.

--
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);

---

Den Tue, 24 Jan 2006 19:34:12 +0100 skrev Kasper Dupont:
> Kent Friis wrote:
>>
>> Den Tue, 24 Jan 2006 18:10:50 +0100 skrev Henning Wangerin:
>> >
>> > Er der ikke en lettere måde til simplthen at slå /backup ihjel?
>>
>> Det eneste alternativ jeg lige kan se er debugfs, slette directory-
>> indgangen, og så lade fsck redde tråddene ud - men der er både
>> risikabelt, og kunne nemt gå hen og tage endnu længere tid.
>
> Jeg tror ikke engang det hjælper. fsck vil jo opdage, at der
> er et fuldstændigt konsistent directory helt uden links til,
> og så vil den bare oprette et link i /lost+found.

Det kunne der være noget om, selvom jeg ikke mener det var det der
skete dengang jeg legede med det (voldtest af fsck) - men det var i
det 20'de århundrede, så det er ikke sikkert jeg husker detaljerne.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

On Tue, 24 Jan 2006 17:17:33 +0000, Kent Friis wrote:

> Det eneste alternativ jeg lige kan se er debugfs, slette directory-
> indgangen, og så lade fsck redde tråddene ud - men der er både
> risikabelt, og kunne nemt gå hen og tage endnu længere tid.

Det lyder lige lovligt farligt. Resten af disken skulle gerne overleve

---

Henning Wangerin wrote:
>
> Hejsa!
>
> Jeg har en disk hvorpå der ligger cd 50Gb backupfiler som jeg skal ha
> slettet.
> Filerne er taget med
> cp -al * `date`
> dvs der er ikke kun mange men en ala helvedes masse links til et hav af
> filer.
>
> Indtil nu har rm -rf * kørt i halvandet døgn og har fået slettet ca
> 10% af filerne.
>
> Er der ikke en lettere måde til simplthen at slå /backup ihjel?

Du kan bruge mkfs til at slette hele filsystemet.

Ellers vil jeg sige, prøv at finde ud af, hvad der er
flaskehalsen. Er det et spørgsmål om CPU, RAM, søgetider eller
overførselshastighed?

Prøv evt. at bruge strace på den kørende rm process for at se,
om den laver nogle overflødige systemkald.

Hvor hurtigt kan en find løbe gennem det directory du er i gang
med at slette? Har du nogensinde prøvet at køre en find på det?

En af mine venner har nogle gange oplevet at rm gik i uløkke når
man prøvede at fjerne filer fra et xfs filsystem med fejl på. En
genstart af maskinen, en fsck af filsystemet og så en ny rm
kommando løste vistnok problemet.

--
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);

---

On Tue, 24 Jan 2006 19:39:41 +0100, Kasper Dupont wrote:

> Du kan bruge mkfs til at slette hele filsystemet.

I know, men nu er det pågældende dir kun en (lille) del af disken, hvor
resten skal bruges

> Hvor hurtigt kan en find løbe gennem det directory du er i gang med at
> slette? Har du nogensinde prøvet at køre en find på det?

Nej det har jeg ikke, men der er men jeg prøvede lige på en del af
træet (backupen for den største server). Den tager 3 minutter, finder
ca 200.000 filer, og denne ene server er backupet up en gang i timen ca
400 gange. Filer der ikke er ændret mellem backups er blot hard-linken
til den samme fysiske file, men kigger vi på sele dir-strukturen, er den
på ca 80.000.000 filer

> En af mine venner har nogle gange oplevet at rm gik i uløkke når man
> prøvede at fjerne filer fra et xfs filsystem med fejl på. En genstart
> af maskinen, en fsck af filsystemet og så en ny rm kommando løste
> vistnok problemet.

Den kører ext2, men jeg kører da alligevel lige en fsck på den for en
sikkerheds-skyld. Vender tilbage med resultatet.

---

Henning Wangerin wrote:
>
> Den tager 3 minutter, finder ca 200.000 filer,

Jeg prøvede lige på mit eget homedir. Der tager find 40 sekunder
om ca. 36.000 filer. Det passer meget godt med dine tal. I mit
tilfælde var det I/O, der var flaskehalsen. Var det først cachet,
så kunne jeg køre kommandoen igen på blot 0.1 sekund.

> og denne ene server er backupet up en gang i timen ca
> 400 gange. Filer der ikke er ændret mellem backups er blot hard-linken
> til den samme fysiske file, men kigger vi på sele dir-strukturen, er den
> på ca 80.000.000 filer

Hvis du efterfølgende kører en find kommando på et andet af de
400 eksemplarer vil jeg gætte på at den kører hurtigere fordi
du allerede har en hel del inodes i cachen. Så vidt jeg lige kan
regne ud skal du bruge ca. 114MB RAM til inode cachen.

Hvor meget RAM har du? Og prøv at køre slabtop imens den arbejder
så vi kan få en fornemmelse af, om der er RAM nok til at cache de
relevante ting.

Jeg har en idé til hvordan man måske hurtigt kan få fyldt cachen
op med directories. Man kunne prøve at køre 400 find kommandoer i
parallel på hvert sit directory og så håbe på, at elevatoralgoritmen
får det til at gå hurtigere end det ville have gjort sekventielt.

Det hjælper selvfølgelig kun, hvis der er RAM nok til at cache det
hele.

>
> Den kører ext2,

Hvad er det største antal directory entries du har i et enkelt
directory? ext2 er ikke glad for alt for store directories. Man
får nok den bedste performance hvis alle directories har 100-1000
indgange hver.

--
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);

---

Kasper Dupont wrote:
>
> Jeg har en idé til hvordan man måske hurtigt kan få fyldt cachen
> op med directories. Man kunne prøve at køre 400 find kommandoer i
> parallel på hvert sit directory og så håbe på, at elevatoralgoritmen
> får det til at gå hurtigere end det ville have gjort sekventielt.

Altså noget i retning af:
for N in * ; do ( nice nice find "$N" & ) done | wc

> Det hjælper selvfølgelig kun, hvis der er RAM nok til at cache det
> hele.

--
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);

---

On Wed, 25 Jan 2006 11:20:58 +0100, Kasper Dupont wrote:

> Hvor meget RAM har du?

~400Mb

> Og prøv at køre slabtop imens den arbejder så vi
> kan få en fornemmelse af, om der er RAM nok til at cache de relevante
> ting.

Den er desværre ikke installeret på maskinen

> Jeg har en idé til hvordan man måske hurtigt kan få fyldt cachen op med
> directories. Man kunne prøve at køre 400 find kommandoer i parallel på
> hvert sit directory og så håbe på, at elevatoralgoritmen får det til
> at gå hurtigere end det ville have gjort sekventielt.

Hvorfor skulle det blive bedre af det? Det har jeg lidt svært ved at se.

> Det hjælper selvfølgelig kun, hvis der er RAM nok til at cache det hele.

Klart.

> Hvad er det største antal directory entries du har i et enkelt directory?
> ext2 er ikke glad for alt for store directories. Man får nok den bedste
> performance hvis alle directories har 100-1000 indgange hver.

Det vil typisk ikke være over det antal.

/backup/ har x dirs til data for x servere.

/backup/server1/ har op til 400 disr med snapsnots. Derunder ligger der
helt normale directory-trees som du kan finde på din egen maskine. Typisk
et dump af / og evt andre mountpoints til andre file-system som skal
backes up.


/Henning

---

Henning Wangerin wrote:
>
> On Wed, 25 Jan 2006 11:20:58 +0100, Kasper Dupont wrote:
>
> > Hvor meget RAM har du?
>
> ~400Mb

Det burde være nok til de 200.000 inodes. Men det er ikke
nok til at cache 80.000.000 directory entries. Prøv at
kigge i slabinfo efter hvor mange den egentlig har cachet.

> > Og prøv at køre slabtop imens den arbejder så vi
> > kan få en fornemmelse af, om der er RAM nok til at cache de relevante
> > ting.
>
> Den er desværre ikke installeret på maskinen

Så må du nok selv kigge på /proc/slabinfo. Ellers kan du
bruge https://www.daimi.au.dk/~kasperd/linux_kernel/slabs
(virker kun på Linux 2.4).

>
> > Jeg har en idé til hvordan man måske hurtigt kan få fyldt cachen op med
> > directories. Man kunne prøve at køre 400 find kommandoer i parallel på
> > hvert sit directory og så håbe på, at elevatoralgoritmen får det til
> > at gå hurtigere end det ville have gjort sekventielt.
>
> Hvorfor skulle det blive bedre af det? Det har jeg lidt svært ved at se.

Det kommer nok an på hvor fragmenteret disken er. Det kan
i teorien også gå hen at blive værre. Men hvis directory
strukturen ligger på en sådan måde, at find skal lave
mange søgninger, så kunne de mange parallelle find
kommandoer hjælpe. Det burde jo betyde, at kernen hele
tiden har flere hundrede valgmuligheder når der skal
indlæses en sektor. Så kan den jo for det meste vælge en,
der giver en kort søgning.

--
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);

---

Jeg ved ikke helt hvorfor, men nu begynder der af en eller anden grund at
blive frigivet disk-plads.

On Wed, 25 Jan 2006 18:12:47 +0100, Kasper Dupont wrote:

> Det burde være nok til de 200.000 inodes. Men det er ikke nok til at
> cache 80.000.000 directory entries. Prøv at kigge i slabinfo efter hvor
> mange den egentlig har cachet.

Hvis jeg tolker outputtet rigtigt ligger der ca 150.000 inodes i cachen.

>> Hvorfor skulle det blive bedre af det? Det har jeg lidt svært ved at
>> se.
>
> Det kommer nok an på hvor fragmenteret disken er. Det kan i teorien
> også gå hen at blive værre. Men hvis directory strukturen ligger på
> en sådan måde, at find skal lave mange søgninger, så kunne de mange
> parallelle find kommandoer hjælpe. Det burde jo betyde, at kernen hele
> tiden har flere hundrede valgmuligheder når der skal indlæses en
> sektor. Så kan den jo for det meste vælge en, der giver en kort
> søgning.

Ahhh på den måde. Så giver det jo mening alligevel

Men som sagt, så begynder der at forsvinde data nu, så det kan vel også
være et spørgsmål om at have en lidt længere lunte mht hvor hurtigt
det skal gå. Der er trods alt tale om en hel del data

Tak for hjælpen ndtil nu.

/Henning

---

Henning Wangerin wrote:
>
> Jeg ved ikke helt hvorfor, men nu begynder der af en eller anden grund at
> blive frigivet disk-plads.

Den er måske nået så langt, at nu har den omsider fået fjernet
samtlige links til nogle af filerne. Den plads, en fil optog,
bliver jo først frigivet, når det sidste link bliver fjernet.

>
> On Wed, 25 Jan 2006 18:12:47 +0100, Kasper Dupont wrote:
>
> > Det burde være nok til de 200.000 inodes. Men det er ikke nok til at
> > cache 80.000.000 directory entries. Prøv at kigge i slabinfo efter hvor
> > mange den egentlig har cachet.
>
> Hvis jeg tolker outputtet rigtigt ligger der ca 150.000 inodes i cachen.

Det er så lidt skidt hvis du har et working set på 200.000.
Det betyder jo nok 25% misses der hver resulterer i disk
tilgang. (Det kan være endnu værre hvis der bruges en LRU
replacement og inodes tilgås i samme rækkefølge ved hvert
gennemløb). Hvis jeg har ret i den fornemmelse, så betyder
det, at det kunne være gået mange gange hurtigere hvis du
havde haft en halv gang mere RAM.

Hvad angår fortolkning af oplysninger om slabs, så er det
aktive objects du skal kigge efter. I /proc/slabinfo er det
den første søjle efter navnet.

>
> Men som sagt, så begynder der at forsvinde data nu, så det kan vel også
> være et spørgsmål om at have en lidt længere lunte mht hvor hurtigt
> det skal gå. Der er trods alt tale om en hel del data

Ja, det lyder jo som om den vil blive færdig indenfor en
overskuelig fremtid. Og så er der jo grænser for, hvor
meget det kan betale sig at lede efter måder at speede den op.

I øvrigt har jeg en anden idé til hvordan man måske kan få
lidt mere fart på sletningen i dit specifikke tilfælde.

Du har sikkert kørt en kommando noget i retning af:
rm -rf /backup/*

Men så skal den jo tilgå samtlige inodes for hver enkelt
backup. Og hvis ikke de kan være i RAM, så har du nok noget
nær et worst case access pattern. I stedet kunne du måske
skrive:

rm -rf /backup/*/usr

Så vil den kun fjerne den del af filerne som har ligget i
/usr. De inodes kan måske ligge i RAM hvorved sletningen
sikkert går langt hurtigere. Så gentager du bare for hvert
directory. Du skal selvfølgelig lige huske at rette detaljerne
hvis dine backups er struktureret anderledes end jeg har
forestillet mig.

--
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);

---

On Thu, 26 Jan 2006 00:10:49 +0100, Kasper Dupont wrote:

> Henning Wangerin wrote:
>>
>> Jeg ved ikke helt hvorfor, men nu begynder der af en eller anden grund
>> at blive frigivet disk-plads.
>
> Den er måske nået så langt, at nu har den omsider fået fjernet
> samtlige links til nogle af filerne. Den plads, en fil optog, bliver jo
> først frigivet, når det sidste link bliver fjernet.

Den er blevet færdig.

>> Hvis jeg tolker outputtet rigtigt ligger der ca 150.000 inodes i cachen.
>
> Det er så lidt skidt hvis du har et working set på 200.000. Det betyder
> jo nok 25% misses der hver resulterer i disk tilgang. (Det kan være endnu
> værre hvis der bruges en LRU replacement og inodes tilgås i samme
> rækkefølge ved hvert gennemløb). Hvis jeg har ret i den fornemmelse,
> så betyder det, at det kunne være gået mange gange hurtigere hvis du
> havde haft en halv gang mere RAM.

Ja det er jeg slet ikke i tvivl om, med detr var der nu ikke i maskinen


> I øvrigt har jeg en anden idé til hvordan man måske kan få lidt mere
> fart på sletningen i dit specifikke tilfælde.
>
> Du har sikkert kørt en kommando noget i retning af: rm -rf /backup/*

Korrekt.

> Men så skal den jo tilgå samtlige inodes for hver enkelt backup. Og
> hvis ikke de kan være i RAM, så har du nok noget nær et worst case
> access pattern. I stedet kunne du måske skrive:
>
> rm -rf /backup/*/usr

Lyder meget fornuftigt.

> Så vil den kun fjerne den del af filerne som har ligget i /usr. De
> inodes kan måske ligge i RAM hvorved sletningen sikkert går langt
> hurtigere. Så gentager du bare for hvert directory. Du skal
> selvfølgelig lige huske at rette detaljerne hvis dine backups er
> struktureret anderledes end jeg har forestillet mig.

Det vil jeg skrive mig bag øret til en anden gang. Mange tak for tippet.

/Henning

---

Henning Wangerin wrote:

> Hejsa!
>
> Jeg har en disk hvorpå der ligger cd 50Gb backupfiler som jeg skal ha
> slettet.
> Filerne er taget med
> cp -al * `date`
> dvs der er ikke kun mange men en ala helvedes masse links til et hav af
> filer.
>
> Indtil nu har rm -rf * kørt i halvandet døgn og har fået slettet ca
> 10% af filerne.

Du er sikker på at der ikke er block fejl på den disk der gør at den
staller?

Mads

--
Mads Bondo Dydensborg mads@dydensborg.dk http://www.madsdydensborg.dk/

The low quality of [MP3] files should prevent this format from threatening
control of our intellectual property. Why would anyone listen to a sub-CD
quality song when they can easily buy the CD at the local Tower Records?
- RIAA head, Hillary Rosen, March 1997

---

On Tue, 24 Jan 2006 20:27:55 +0100, Mads Bondo Dydensborg wrote:

> Du er sikker på at der ikke er block fejl på den disk der gør at den
> staller?

Den sletter lystigt filerne, der er bare forbandet mange. +80.000.000 !

/Henning

---

Henning Wangerin <news_via_pan+041124@hpc.dk> writes:

> Indtil nu har rm -rf * kørt i halvandet døgn og har fået slettet ca
> 10% af filerne.

Kører disken synkront, altså at der skrives ved hver ændring? Det kan
man jo ændre...

--
Thorbjørn Ravn Andersen

---

On Tue, 24 Jan 2006 20:34:11 +0100, Thorbjørn Ravn Andersen wrote:

> Kører disken synkront, altså at der skrives ved hver ændring? Det kan
> man jo ændre...

Se det kunne måske være en løsning på problemet.

Hints til hvordan? .....

---

Henning Wangerin <news_via_pan+041124@hpc.dk> writes:

> On Tue, 24 Jan 2006 20:34:11 +0100, Thorbjørn Ravn Andersen wrote:
>
> > Kører disken synkront, altså at der skrives ved hver ændring? Det kan
> > man jo ændre...
>
> Se det kunne måske være en løsning på problemet.
>
> Hints til hvordan? .....

mount options. Disse er operativsystem- og filsystemafhængige.

Har du eventuelt overvejet en anden backupstrategi?
--
Thorbjørn Ravn Andersen

---

On Wed, 25 Jan 2006 00:34:07 +0100, Thorbjørn Ravn Andersen wrote:

>> Hints til hvordan? .....
>
> mount options. Disse er operativsystem- og filsystemafhængige.
>
> Har du eventuelt overvejet en anden backupstrategi?

Der er tale om en disk der _har_ været brugt til backup på
forsøgsbasis. Nu er systemet flyttet over på en dedikeret maskine, som
henter data via rsync en gang i timen.

Nu vil jeg bare godt kunne bruge den brugte plads på disken til noget
mere fornuftigt. Jeg skal næppe bruge backupdata som er 1½ år gamle
alligevel

/Henning

---

Henning Wangerin <news_via_pan+041124@hpc.dk> writes:

> On Tue, 24 Jan 2006 20:34:11 +0100, Thorbjørn Ravn Andersen wrote:
>
>> Kører disken synkront, altså at der skrives ved hver ændring? Det kan
>> man jo ændre...
>
> Se det kunne måske være en løsning på problemet.
>
> Hints til hvordan? .....

man mount på GNU/Linux siger vist det hele, men vær opmærksom på at
asynkron er std., så det er ikke sikkert at det hjælper dig.
--
mvh Jes Vestervang @ Debian Sid