On Monday 10 March 2003 06:48 am, Mark Weaver wrote:
et wrote:
On Monday 10 March 2003 07:17 am, Mark Weaver wrote:
Hi list,
I noticed this yesterday after receiving an error message from Mozilla that it couldn't send a message. So far I've been all over the filesystem every way I know how, but still can't find a reason for this condition.
So far I've phyiscally examined the filesystem with mc and du to see if I could find an extra large file somewhere, but nothing is popping out. The only thing on the "/" filesystem is everything but /var and /usr. I'm suspicious of the manner in which /mnt may be affecting the root filesystem.
Any ideas?
Filesystem Size Used Avail Use% Mounted on /dev/hda1 718M 674M 7.6M 99% / none 62M 0 61M 0% /dev/shm /dev/hda10 618M 308M 310M 50% /home /dev/hdc1 643M 611M 0 100% /mnt/arc /dev/hda11 3.5G 2.1G 1.2G 61% /mnt/arc_2 /dev/hda6 1.4G 1.4G 26M 99% /usr /dev/hda7 934M 538M 349M 61% /var /dev/hda9 3.9G 906M 2.8G 24% /var/ftp /dev/hda8 1.1G 179M 869M 18% /var/www
bud,,, each entry in /mnt takes about 4 bytes in the "/" filespace so I would bet that ai'nt it tried deleting (or cleaning) /tmp on boot?
Ha! My suspicions were correct. It "was" a problem with one if the dir's in /mnt. Following Stephens' suggestion I umounted everything mounted under /mnt and then ran the "du" command. /mnt showed up as weighing in at 609M. Just a few more bytes then 4, eh?
So, liberally wacking the contents of that directory, (which happened to be part of my mp3 collection) the weight if "/" is now back down to 10% or 66M.
The quesiton now is "why" was just /mnt/mp3 effecting "/" and not /mnt/arc (which is 650M and at 100%) or /mnt/arc_2 which is currently at 61% (2.1GB)?
By they way...thanks to all that responded. Your comments and suggestions helped me to elliminate possible causes and focus in the direction of the real culprit.
A little background info:
the dir's /mnt/arc, /mnt/arc_2, and /mnt/mp3 are shared over nfs and samba. while I don't have any trouble RW to ?mnt/arc, /mnt/arc_2 there were some problems with /mnt/mp3. It would only allow R access to the filesystem. Until yesterday when I shut down nfs and samba, umounted /mnt/mp3 and then chown'd /mnt/mp3 to user.root, and then chmod'd it to 777. Once that was done I was able to write to that partition from the client machines over nfs and samba, but I suspect that it was at that time when "/" began to be 100% full.
whats up with that?
You had /mnt/mp3 created locally instead of mounted remotely--when the remote mount is in place, it will overtake the local, but when it is not you will have a valid local directory (since it is defined as a directory to be a mount point.
You therefore did not have the remote mount working when you wrote to /mnt/mp3. Usually ro write to a remote nfs system when writes are blocked you have to check permissions on BOTH machines, and define a way for a write to happen... Check the remote mount through remote linuxconf or webmin.
Civileme
Thanks guys. what you're saying makes a great deal of sense.
Mark
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
