my 40Gb / partition is full -> very strange...[SOLVED]

[bernd2]

The problem:

My / partition is full, although I have nothing specials installed and if so, it's still very strange. I have found out that / also incalculates other mounted partitions. To be concrete, / is full because the 32Gb big /media/disk partition is added to / with size calculations.

My thought was that /media/disk is not well mounted in fstab, but I checked:

# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# /dev/sda1
UUID=db930d0b-9d26-4f51-8f93-c0a233ee6097 / ext3 nouser,relatime,errors=remount-ro,atime,auto,rw,dev,exec,suid 0 1
# /dev/sda2
UUID=f484c2c8-32de-4b5d-89e9-1ca164599552 none swap sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,utf8,atime,noauto,rw,dev,exec,suid 0 0
/dev/sda5 /media/disk ext3 defaults 0 0

my /media/disk is mounted with defaults option and it works just fine, just my / partition does very weird...


grtz& thx in advance!

[dibl]

Re: my 40Gb / partition is full -&gt; very strange...

Please post the output of

sudo blkid

[bernd2]

Re: my 40Gb / partition is full -&gt; very strange...

/dev/sda1: UUID="db930d0b-9d26-4f51-8f93-c0a233ee6097" TYPE="ext3"
/dev/sda2: TYPE="swap" UUID="f484c2c8-32de-4b5d-89e9-1ca164599552"
/dev/sda5: UUID="335c992c-fea6-43c6-95f3-d69d8de5b521" SEC_TYPE="ext2" TYPE="ext3"

[dibl]

Re: my 40Gb / partition is full -&gt; very strange...

OK, I would advise doing two things, both of which are virtuous things to do, but neither of which is guaranteed to fix that odd "filesystem full" situation.

1. In your fstab file, you have conflicting "atime" options on your root filesystem. I personally prefer "noatime" to either "relatime" or "atime". I'll let you and Mr. Google research the Linux "atime" filesystem option and learn why, but for now just open /etc/fstab in your favorite text editor, delete "relatime" and change "atime" to "noatime", save it, and then issue

sudo mount -a

in the console to remount it. I assume you mean to have the "nouser" option on it -- I don't do that with mine, but I'm the only user in the house, so it doesn't matter.

2. I strongly recommend changing the mount method to "mount by UUID" for your /dev/sda5 partition. Maybe it's just philosophical, and we'll probably hear shouting from the traditionalists in the group, but Debian has changed to adopt "mount by UUID" as the standard, and it strikes me it is better to accept the new method than fight it and endure the consequences. So, I'm saying change the line

/dev/sda5 /media/disk ext3 defaults 0 0

so it reads

UUID=335c992c-fea6-43c6-95f3-d69d8de5b521 /media/disk ext3 auto,users,rw,exec,noatime 0   2

save it and remount.

Now you can check

df -h

and see if anything has improved.

Hope it helps ...


MORE: http://www.tuxfiles.org/linuxhelp/fstab.html

http://tldp.org/LDP/solrhe/Securing-...hap6sec73.html

http://kerneltrap.org/node/14148

[bernd2]

Re: my 40Gb / partition is full -&gt; very strange...

ok I've done that, but the problem remains...

bernd@bdesktop:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 38G 36G 114M 100% /
varrun 2.0G 100K 2.0G 1% /var/run
varlock 2.0G 0 2.0G 0% /var/lock
udev 2.0G 56K 2.0G 1% /dev
devshm 2.0G 0 2.0G 0% /dev/shm
lrm 2.0G 44M 1.9G 3% /lib/modules/2.6.24-21-generic/volatile
/dev/sda5 378G 41G 318G 12% /media/disk

[rpw]

Re: my 40Gb / partition is full -&gt; very strange...

Can you please show the output of the following command:

sudo du -h --max-depth=1 /

I'd bet the problem is apt-cache, which could be solved with the following command

sudo apt-get clean

But to be sure please do the first command before doing anything else.

Regards,

rpw

[bernd2]

Re: my 40Gb / partition is full -&gt; very strange...

output:

7.8M /sbin
16K /lost+found
1.4G /home
3.2G /usr
du: cannot access `/proc/10966/task/10966/fd/4': No such file or directory
du: cannot access `/proc/10966/task/10966/fdinfo/4': No such file or directory
du: cannot access `/proc/10966/fd/4': No such file or directory
du: cannot access `/proc/10966/fdinfo/4': No such file or directory
0 /proc
41G /media
0 /sys
4.0K /initrd
4.0K /srv
331M /lib
68K /dev
6.3M /bin
3.0M /opt
31G /var
13M /etc
39M /boot
3.7M /lib32
648K /root
4.0K /mnt
84K /tmp
76G /

[dibl]

Re: my 40Gb / partition is full -&gt; very strange...

31G /var

There's your bad boy -- /var shouldn't be over 500M.

[rpw]

Re: my 40Gb / partition is full -&gt; very strange...

So what I can see the problem is /var.

Can you please show the output of the 2 following commands:

sudo du -h --max-depth=1 /var/

If /var/cache ist the biggest one (and I bet it is), please show the output of

sudo du -h --max-depth=1 /var/cache

And then (I guess) the folder /var/cache/apt is the biggest one. If it is, the problem can be solved with the command

sudo apt-get clean

What does this mean? When you install programs (no matter if you do with apt-get install or with Synaptic or Adept), the packages will be downloaded to the folder /var/cache/apt, and from there they will be installed. The packages will NOT be deleted after the installation, so in case you delete the programs and install it again, the packages do not have to be downloaded again (if there is no new version of the package). So sudo apt-get clean will just clean the folder /var/cache/apt and free up disc space.

Regards,

rpw

[bernd2]

Re: my 40Gb / partition is full -&gt; very strange...

not exactly...

bernd@bdesktop:~$ sudo du -h --max-depth=1 /var/
[sudo] password for bernd:
4.0K /var/mail
72K /var/spool
0 /var/lock
3.4M /var/backups
4.0K /var/local
129M /var/lib
4.0K /var/opt
537M /var/cache
30G /var/log
100K /var/run
8.0K /var/lib32
4.0K /var/crash
11M /var/tmp
31G /var/
bernd@bdesktop:~$ sudo du -h --max-depth=1 /var/log
4.0K /var/log/apparmor
1.2M /var/log/cups
4.0K /var/log/dist-upgrade
4.0K /var/log/news
88K /var/log/apt
4.0K /var/log/unattended-upgrades
12K /var/log/fsck
4.0K /var/log/samba
616K /var/log/installer
30G /var/log

apparently the files in /var/log take extremely much. How does this happen? May I just delete these files?

[bernd2]

Re: my 40Gb / partition is full -&gt; very strange...

I looked in the folder /var/log and found 2 files that take 29Gb:

syslog.0
user.log.0

I tried to open them with kate, but kate crashes when opening these files.

[Snowhog]

Re: my 40Gb / partition is full -&gt; very strange...

The syslog and user.log files are created/maintained by the system. They can be deleted, and they will again be created as required.

Open a console and type:

sudo rm /var/log/syslog.0 && sudo rm /var/log/user.log.0

The fact that these two files are so large indicates that at some point something 'went wrong.' On a normal system that has been in use for some time, you should see something like this for these two files in /var/log:

-rw-r----- 1 syslog adm 218 2008-10-22 18:29 syslog
-rw-r----- 1 syslog adm 81637 2008-10-22 18:17 syslog.0
-rw-r----- 1 syslog adm 31096 2008-10-21 18:51 syslog.1.gz
-rw-r----- 1 syslog adm 30971 2008-10-20 09:23 syslog.2.gz
-rw-r----- 1 syslog adm 32633 2008-10-19 08:24 syslog.3.gz
-rw-r----- 1 syslog adm 18989 2008-10-18 09:33 syslog.4.gz
-rw-r----- 1 syslog adm 41577 2008-10-17 14:17 syslog.5.gz
-rw-r----- 1 syslog adm 27989 2008-10-14 16:17 syslog.6.gz
-r

-rw-r----- 1 syslog adm 3720 2008-10-22 18:09 user.log
-rw-r----- 1 syslog adm 7440 2008-10-19 08:19 user.log.0
-rw-r----- 1 syslog adm 299 2008-10-12 08:15 user.log.1.gz
-rw-r----- 1 syslog adm 400 2008-10-05 09:50 user.log.2.gz
-rw-r----- 1 syslog adm 510 2008-09-28 09:30 user.log.3.gz

[bernd2]

Re: my 40Gb / partition is full -&gt; very strange...

problem solved.

Big thx to you guys!

[tinker]

[OT - UUID] -Re: my 40Gb / partition is full -&gt; very strange...

2. I strongly recommend changing the mount method to "mount by UUID" for your /dev/sda5 partition. Maybe it's just philosophical, and we'll probably hear shouting from the traditionalists in the group, but Debian has changed to adopt "mount by UUID" as the standard, and it strikes me it is better to accept the new method than fight it and endure the consequences. So, I'm saying change the line

Kewl, "traditionalists", perhaps he was referring to old guys like me, who are accustomed to the old method and are resistant to change. <chuckle>

It's just because I have trouble remembering a long string and I can often remember which device I put something on (at least , I used to be able to remember). Actually, for a simple workstation installation I like mounting by label. When I set up my partitions, I choose labels like, "/"; or "root"; or "Kubuntu" and "home" and "data" and "music" and so on. The mount command accepts the -L, to mount by the label you gave to the the partition and fstab mounting can mount by label too. Isn't it great that we have such choice that we can all choose what works best for us personally in any given situation.

However, I do agree with dibl, the UUID method has merit. That second "U", "unique" is something that could have distinct advantages. And, as dibl wrote, it's the decision developers have made for the future, so I think it's wise to follow in case a time comes when other methods are deprecated. In my opinion, that "unique" makes it a bit less likely that one will mount something in the wrong place by accident and cause a problem, which I have seen people do quite a bit over the years. It might be more difficult to make a mistake if one copies and pastes from blkid.tab or from the results of the command given which lists the UUIDs. It has the potential to help with some of the problems with removable drives which sometimes end up on a different device node than what we expect when plugged and unplugged.

So, my recommendation is the same as dibl's, regarding UUID mounting. It's the future. For us traditionalists, it's adapt or risk falling behind.