Dan Track wrote:
...
[root@diamond root]# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sda1 1035660 476164 506888 49% /
/dev/sdb1 17140848 11505004 4765124 71% /opt
none 513960 0 513960 0% /dev/shm
/dev/sda2 3099292 979196 1962660 34% /usr
[root@diamond root]# ls -laRib /var/spool/mqueue
/var/spool/mqueue:
total 3724384
15374 drwxr-xr-x 2 root mail 311296 Dec 4 12:46 .
43877 drwxr-xr-x 11 root root 4096 Jul 13 13:33 ..
[root@diamond root]# du /var/spool/mqueue
3724380 /var/spool/mqueue
I don't see any way with these numbers that /var/spool/mqueue can really
be 3.7G.
First off, df says the whole root file system is only 1G (with ~0.5G
used). How can mqueue be 3.7G?
Second, even though directories don't release their disk space when they
shrink, I'd be very surprised if the actual size was 3.7G. If every
filename were the max of 255 characters, you'd need almost 15 million
files to account for a 3.7G directory.
And as you said originally, du and ls disagree about the size.
All this would make me want to be sure there's no problem with the
filesystem.
Have you run a full fsck on the partition lately? If not (and I believe
the default for ext3 partitions is to never run a full fsck unless you
ask for it), you can use something like shutdown -rF (reboot, force
fsck) to reboot and run one.
If fsck gives a clean bill of health, I'd just delete mqueue and
re-create it with something like this:
# cd /var/spool
# rmdir mqueue
# install -d -m755 -oroot -gmail mqueue
<Joe