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
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
