---

Hej,

Jeg har en maskine der er 100% fuld på /, men det burde der
slet ikke være, da der kun er OS filer på denne partition og
brugere kun tilgår den via FTP/Samba der giver adgang til
diske under /mnt

[root@yoda /]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 4.9G 4.7G 0 100% /
/dev/sda2 4.9G 3.8G 839M 83% /mnt/disk1
/dev/sda4 62G 23G 37G 38% /mnt/disk2
/dev/sdb1 74G 36G 35G 51% /mnt/disk3
none 125M 0 125M 0% /dev/shm

Jeg troede det måske var en stor temporær samba/cups fil, men
kunne intet finde, så jeg prøvede at reboote maskinen, men
det hjalp ikke. Og:

[root@yoda /]# for i in *; do du -sh $i; done
4.6M bin
11M boot
420K dev
24M etc
127M home
4.0K initrd
80M lib
16K lost+found
4.0K misc
65G mnt
4.0K opt
301K proc
11M root
12M sbin
12K tmp
1.1G usr
258M var

Her kan jeg ikke se hvor filen skulle være. Jeg kører
RH9, kerne 2.4.20.

Alle forslag modtages med kyshånd :)

Morten

---

Den Thu, 18 Sep 2003 23:36:20 -0700, skrev Morten:

Har du brugt alle inoder på / ?


/sv-e

---

usenet@kikobu.com (Morten) writes:

>Jeg har en maskine der er 100% fuld på /, men det burde der
>slet ikke være, da der kun er OS filer på denne partition og
>brugere kun tilgår den via FTP/Samba der giver adgang til
>diske under /mnt

Hvis du unmounter /mnt/disk[123], hvor meget fylder /mnt så?

Mvh.
   Klaus.

---

Morten wrote:

> Jeg har en maskine der er 100% fuld på /, men det burde der slet ikke
> være, da der kun er OS filer på denne partition og brugere kun tilgår
> den via FTP/Samba der giver adgang til diske under /mnt

Er du helt sikker på at der ikke ligger mere under /mnt end du tror?

> [root@yoda /]# df -h
       ^^

Hvis du vil have præcis hjælp, så giv præcis information. Afrundinger
er ingen hjælp.

> Filesystem Size Used Avail Use% Mounted on
> /dev/sda1 4.9G 4.7G 0 100% /
^^^^^^^^^^

Ja, det ser sært ud, men det er nok bare fordi der er en del slack space
der ikke kan udnyttes. Jeg skal dog ikke kunne sige det med sikkerhed.

Hvis du kører 'fsck -n /dev/root', så skulle den sige noget om 'x/y
files', hvor x og y er nogle tal. Hvis tallene er ens, eller tæt på
hinanden, så er problemet at du ikke har flere inodes. Det kan tyde på
en blokstørrelse der er valgt forkert i forhold til det disken skulle
bruges til. En anden mulighed kunne måske være et korrupt filsystem,
men det er ikke til at vide hvordan det vil manifestere sig. Specielt
ikke når du ikke fortæller os hvilket filsystem det *er*.

> /dev/sda2 4.9G 3.8G 839M 83% /mnt/disk1
> /dev/sda4 62G 23G 37G 38% /mnt/disk2
> /dev/sdb1 74G 36G 35G 51% /mnt/disk3
> none 125M 0 125M 0% /dev/shm
>
> Jeg troede det måske var en stor temporær samba/cups fil, men kunne
> intet finde, så jeg prøvede at reboote maskinen, men det hjalp ikke.

Nej, det hjælper stort set aldrig at reboote. Dette er ikke Windows!

> Og:
>
> [root@yoda /]# for i in *; do du -sh $i; done
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Gys ... Er du bare glad for at skrive, eller vidste du ikke at man kan
få nøjagtig samme listing med 'du -sh *'? Den eneste forskel er at min
metode ikke fejler, hvis der er mellemrum i filnavnet. Anyway, så er
der her samme problem med at der sker afrundinger. Det var bedre at
bruge 'du -bs *'.

Lad os regne lidt på det (jeg udelader lige de små) ...

> 4.6M bin
> 11M boot
17M
> 24M etc
40M
> 127M home
167M
> 80M lib
247M
> 11M root
258M
> 12M sbin
270M
> 1.1G usr
270+1.1*1024 = 1396M
> 258M var
1654M
> 65G mnt

Her mangler vi så at vide hvor meget der er på *dette* filsystem. Du
skulle have brugt '-x' som parameter til 'du'. Jeg vil dog prøve at
estimere forbruget ud fra 'df' angivelserne. Det kunne også være
interessant at vide hvad 'du -bs /mnt/*' siger.

65-3.8-23-36 = 2.2G

I alt giver det ca. 3.8G, hvilket ikke er i nærheden af hvad der skulle
være. Men som sagt, så er det ikke en nøjagtig metode jeg bruger, da
jeg ikke har nøjagtige tal at gå ud fra.

> Her kan jeg ikke se hvor filen skulle være.

Det er heller ikke nemt at vide. Har du mere til at ligge under /mnt/ ?

> Jeg kører RH9, kerne 2.4.20.

Den information hører til i toppen af beskeden. Det samme gør
informationen om hvilket filsystem der bruges.

> Alle forslag modtages med kyshånd :)

1. Kig under /mnt/
2. Hvis der intet sært er dér, køb en større / harddisk.
3. Hvis ny disk ikke er en mulighed, flyt /usr/ over på en af de større
diske. 'mount -o bind' er din ven.

--
PeKaJe

I respect the institution of marriage. I have always thought that every
woman should marry -- and no man. -- Benjamin Disraeli, "Lothair"

---

Peter Jensen wrote:
....
> Nej, det hjælper stort set aldrig at reboote. Dette er ikke Windows!
....

Hvis der er nogle processer der hænger med åbne filer,
og man sletter disse åbne filer, bliver pladsen jo
ikke frigivet før disse processer dør.

Så vil en reboot hjælpe.

Mogens


--
Mogens Kjaer, Carlsberg A/S, Computer Department
Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
Phone: +45 33 27 53 25, Fax: +45 33 27 47 08
Email: mk@crc.dk Homepage: http://www.crc.dk

---

Den Fri, 19 Sep 2003 10:28:19 +0200 skrev Mogens Kjaer:
>Peter Jensen wrote:
>...
>> Nej, det hjælper stort set aldrig at reboote. Dette er ikke Windows!
>...
>
>Hvis der er nogle processer der hænger med åbne filer,
>og man sletter disse åbne filer, bliver pladsen jo
>ikke frigivet før disse processer dør.
>
>Så vil en reboot hjælpe.

Og hvis bilen løber tør for benzin, hjælper det også at skrotte den
og købe en ny med fyldt tank.

Begge dele er totalt overkill for at løse problem (ingen benzin vs.
slette en fil).

Mvh
Kent
--
You haven't seen _multitasking_ until you've seen Railroad
Tycoon II and Unreal Tournament run side by side

---

leeloo@phreaker.net (Kent Friis) writes:

> >Hvis der er nogle processer der hænger med åbne filer,
> >og man sletter disse åbne filer, bliver pladsen jo
> >ikke frigivet før disse processer dør.
> >
> >Så vil en reboot hjælpe.
>
> Og hvis bilen løber tør for benzin, hjælper det også at skrotte den
> og købe en ny med fyldt tank.
>
> Begge dele er totalt overkill for at løse problem (ingen benzin vs.
> slette en fil).

---

Den 19 Sep 2003 17:32:15 +0200 skrev Thorbjoern Ravn Andersen:
>leeloo@phreaker.net (Kent Friis) writes:
>
>> >Hvis der er nogle processer der hænger med åbne filer,
>> >og man sletter disse åbne filer, bliver pladsen jo
>> >ikke frigivet før disse processer dør.
>> >
>> >Så vil en reboot hjælpe.
>>
>> Og hvis bilen løber tør for benzin, hjælper det også at skrotte den
>> og købe en ny med fyldt tank.
>>
>> Begge dele er totalt overkill for at løse problem (ingen benzin vs.
>> slette en fil).
>
>Problemet er hvis man ikke kan lokalisere den process der har en fil åben.

Så kigger man i /proc/[0-9]*/fd

Mvh
Kent
--
If you think about it, Windows XP is actually the OS that
started as "Microsoft OS/2 NT 3.0"

---

Kent Friis wrote:
> Den 19 Sep 2003 17:32:15 +0200 skrev Thorbjoern Ravn Andersen:
> >leeloo@phreaker.net (Kent Friis) writes:
> >> >Hvis der er nogle processer der hænger med åbne filer,
> >> >og man sletter disse åbne filer, bliver pladsen jo
> >> >ikke frigivet før disse processer dør.
> >> >Så vil en reboot hjælpe.
> >> Og hvis bilen løber tør for benzin, hjælper det også at skrotte den
> >> og købe en ny med fyldt tank.
> >> Begge dele er totalt overkill for at løse problem (ingen benzin vs.
> >> slette en fil).
> >Problemet er hvis man ikke kan lokalisere den process der har en fil åben.
> Så kigger man i /proc/[0-9]*/fd

Hvad hvis det er en kerne-proces så som [loop0]?

--
Lars Kongshøj
http://www.kongshoj.com/

---

Den Sat, 20 Sep 2003 15:53:28 +0200 skrev Lars Kongshøj:
>Kent Friis wrote:
>> Den 19 Sep 2003 17:32:15 +0200 skrev Thorbjoern Ravn Andersen:
>> >leeloo@phreaker.net (Kent Friis) writes:
>> >> >Hvis der er nogle processer der hænger med åbne filer,
>> >> >og man sletter disse åbne filer, bliver pladsen jo
>> >> >ikke frigivet før disse processer dør.
>> >> >Så vil en reboot hjælpe.
>> >> Og hvis bilen løber tør for benzin, hjælper det også at skrotte den
>> >> og købe en ny med fyldt tank.
>> >> Begge dele er totalt overkill for at løse problem (ingen benzin vs.
>> >> slette en fil).
>> >Problemet er hvis man ikke kan lokalisere den process der har en fil åben.
>> Så kigger man i /proc/[0-9]*/fd
>
>Hvad hvis det er en kerne-proces så som [loop0]?

Så ved root forhåbentlig så meget om hvad han har lavet, at han selv
kan finde ud af at umount'e den.

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.

---

Peter Jensen <jdogh001@sneakemail.com> writes:

> Morten wrote:
>
> > Filesystem Size Used Avail Use% Mounted on
> > /dev/sda1 4.9G 4.7G 0 100% /
> ^^^^^^^^^^
> Ja, det ser sært ud, men det er nok bare fordi der er en del slack space
> der ikke kan udnyttes. Jeg skal dog ikke kunne sige det med sikkerhed.

Det er fordi der som standard er reserveret 5% af pladsen til root,
Size og Used viser de rigtige tal der gælder for disken, mens Avail og
Use% viser de tal der gælder for brugere, dvs. efter de 5% er trukket
fra.

--
Kim Hansen | |\ _,,,---,,_ | Det er ikke
Dalslandsgade 8, A708 | /,`.-´` -. ;:-. | Jeopardy.
2300 København S | |,4- ) )-,_. ,\ ( `'-' | Svar _efter_
Tlf: 32 88 60 86 | '---''(_/--' `-'\_) | spørgsmålet.

---

Tak for forslagene. Det viste sig, som flere forslog, at der var
mere under /mnt end tilsigtet. Hver nat kører der en backup procedure
der mounter en extern HD på /mnt/backup, skriver dertil, og unmounter.
Af endnu ukendte grunde var mount fejlet, men exit koden var stadig 0,
hvorfor backup jobbet skrev til sda1 frem for den eksterne HD.

Mvh Morten