Filesystem is full ( /: )

V

Vib3

Code: 
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/ad0s1a    496M    480M    -24M   105%    /
devfs          1.0K    1.0K      0B   100%    /dev
/dev/ad0s1e    496M    2.0K    456M     0%    /tmp
/dev/ad0s1f    286G    2.6G    261G     1%    /usr
/dev/ad0s1d    1.2G    465M    658M    41%    /var


1       /COPYRIGHT
1       /bin
123     /boot
1       /cdrom
0       /compat
1       /dev
1       /dist
1       /entropy
2       /etc
0       /home
6       /lib
1       /libexec
1       /media
1       /mnt
1       /proc
4       /rescue
1       /root
4       /sbin
0       /sys
1       /tmp
2686    /usr
466     /var
---------------
I upgraded from 7.0 to 7.1 (freebsd-update upgrade -r 7.1-RELEASE)
First my var got full, but its fixed now.

Problem /: is full.

Runned fsck / no effect
I got 151M on /

Where is 329M of the data?
 
Here's a way to see where the data has gone:
Code: 
# cd /
# du -sk * | sort -n

The biggest directory will be at the bottom of that list.
 
Code: 
du -sk * | sort -n
0       compat
0       home
0       sys
2       cdrom
2       dev
2       dist
2       media
2       proc
4       entropy
4       mnt
8       COPYRIGHT
12      tmp
54      root
172     libexec
990     bin
1788    etc
3744    rescue
3954    sbin
6030    lib
124936  boot
476624  var
2749610 usr

So in / its /boot with 123M.. But still doesnt explain where is 329M :/
 
Ok.

Any ideas ? How to clean ?

Just kernel there ~120M
Data is maybe corrupted, I think..
 
Have you tried a reboot? This might be a stuck file descriptor hanging on to a file that's already been deleted from under it.
 
DutchDaemon said:
Have you tried a reboot? This might be a stuck file descriptor hanging on to a file that's already been deleted from under it.
Click to expand...

Yeap. Server stopped from responding to network traffic, so I had to power it off.. And there was nothing in messages about that.
 
Code: 
1788    ./etc
2       ./cdrom
2       ./dist
990     ./bin
22      ./boot/defaults
2       ./boot/firmware
124246  ./boot/kernel
2       ./boot/modules
2       ./boot/zfs
124936  ./boot
274     ./lib/geom
6030    ./lib
172     ./libexec
2       ./media
2       ./mnt/usbi
4       ./mnt
2       ./proc
3744    ./rescue
18      ./root/.irssi
2       ./root/.ssh
54      ./root
3954    ./sbin
3368090 .
 
My /boot/kernel only contains about 30MB, I'm wondering why yours has 125MB?
 
tangram said:
That's more or less the size of the binary kernel.
Click to expand...
Is there any other type of kernel?

Code: 
root@maelcum:/boot#du -sk * | sort -n
0       loader.conf
2       boot0
2       boot0sio
2       boot1
2       cdboot
2       device.hints
2       firmware
2       loader.rc
2       mbr
2       modules
2       pmbr
2       screen.4th
2       zfs
4       frames.4th
6       loader.4th
8       beastie.4th
8       boot
8       boot2
8       gptboot
16      loader.help
22      defaults
36      support.4th
272     loader
272     loader.old
288     pxeboot
30202   kernel.old
30738   kernel
 
I once had a similiar problem, found out later that the FS snapshots I had made (in /.snap) were using up the extra space. :P
 
Also, you may want to boot into single-user mode, and check the size of / without any other filesystems mounted. Run du from there. It may be that there's something in /var (the mountpoint directory not the mounted filesystem) or /usr.
 
ephemera said:
I once had a similiar problem, found out later that the FS snapshots I had made (in /.snap) were using up the extra space.
Click to expand...

@vib3: Assuming you haven't abandoned this thread...

ephemera may be on to something with that suggestion. The du -ks invocation doesn't seem to pick up hidden (.) files. I have a quick find test you can run that will pick up said files. These points are demonstrated by the example that follows:
Code: 
%cat /dev/zero > .uh-oh
^C

%du -sk * | sort -n
2	tester.py
1632	foo-install-211.pdf
4036	python
14338	music

%find -x . -size +10000 -exec du -h {} \]

So, in your case, run: 
[code]# find -x / -size +10000 -exec du -h {} \;

See if it tells you a new story.
 
Solved mine problem

I solved the problem for me! I had made a new kernel and didn't remove the old one GENERIC in /boot, so, the / it's 108% full because also the new kernel has 'root' as its owner.

It's now 64% full.

Also be careful if Desktop users run firefox as root... This creates big files in your directory. How you can avoid it: that's why there are adduser, su and sudo.
------------
 
Code: 
%cat /dev/zero > .uh-oh

/: write failed, filesystem is full
cat: stdout: No space left on device

%df -h

Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/ad0s1a    496M    496M    -40M   109%    /
devfs          1.0K    1.0K      0B   100%    /dev
/dev/ad0s1e    496M     50K    456M     0%    /tmp
/dev/ad0s1f    286G    2.6G    261G     1%    /usr
/dev/ad0s1d    1.2G    345M    779M    31%    /var

%find -x / -size +10000 -exec du -h {} \;

 14M    /.snap/.uh-oh
9.3M    /boot/kernel/kernel
 28M    /boot/kernel/kernel.symbols

after removing .uh-oh ->

%df -h
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/ad0s1a    496M    481M    -25M   105%    /
devfs          1.0K    1.0K      0B   100%    /dev
/dev/ad0s1e    496M     50K    456M     0%    /tmp
/dev/ad0s1f    286G    2.6G    261G     1%    /usr
/dev/ad0s1d    1.2G    345M    779M    31%    /var

For me there isnt GENERIC in /boot.
I used freebsd-update.

How do I remove the old kernel ?
 
ncdu helped nicely to getter better image of files in folders.
It said that my /rescue folder is 440.5MB.
/rescue folder is full on files:

Code: 
.
.
-r-xr-xr-x  120 root  wheel  3793072 Apr 19 13:13 tunefs
-r-xr-xr-x  120 root  wheel  3793072 Apr 19 13:13 umount
-r-xr-xr-x  120 root  wheel  3793072 Apr 19 13:13 unlink
-r-xr-xr-x  120 root  wheel  3793072 Apr 19 13:13 vi
-r-xr-xr-x  120 root  wheel  3793072 Apr 19 13:13 whoami
-r-xr-xr-x  120 root  wheel  3793072 Apr 19 13:13 zcat

Should they be rather links and whats the best way to make them links ?
 
And where would you like to link to? To the executables that are on your damaged file system, which is why you're using the executables in /rescue?

rescue(8)
 
You must log in or register to reply here.
Back
Top