On 2020-08-19 17:47, Vincent wrote: > Hello, > > > After several days, I have to reboot my machine because of mfs full. This is > not the first time. > I have few mfs on this machine, but I observe that this is always a full > filesystem on /tmp after +40 days of uptime. > But on other mfs, I have very low filesystem activity. > > > Am I the only one having such problem ?
yes. and no. :) Normal Unix Behavior, and nothing to do with MFS. (I think) (for the record, I use mfs extensively some systems I run that get a significant benefit from it, have done so for many many years. Only problem I've ever run into is being that MFS systems shine when for with lots of tiny files, it's the ONLY time I've ever run out of i-nodes before running out of disk space. Not really an MFS problem, of course.) ... > obsd-fw/tmp# du -h /tmp > 1.0K /tmp/.X11-unix > 1.0K /tmp/.ICE-unix > 1.0K /tmp/vi.recover > 11.0K /tmp > obsd-fw/tmp# df -h /tmp > Filesystem Size Used Avail Capacity Mounted on > mfs:71474 991M 991M -49.5M 105% /tmp > obsd-fw/tmp# uptime > 7:22PM up 57 days, 17:58, 1 user, load averages: 0.08, 0.16, 0.15 > obsd-fw/tmp# ps aux | grep mfs > root 71474 0.0 12.4 1049016 1016980 ?? S 22Jun20 1:25.23 > /sbin/mount_mfs -o rw -s 1024m swap /tmp see... "du" and "df" show two different things. "df" shows how much unallocated space you have. It's very accurate. You can create a file as big as "df" shows you have available. "du" shows how much space normal files have taken up. It's also very accurate. It will show you how much space will be freed up if you delete those files. However, you can have Unix do some seemingly strange stuff, at least strange for those of us who cut our teeth on single-user systems. Unix lets programs do funny stuff, like delete an open file. That removes the file handle (what "du" looks at), but does not release disk space (what df looks at) until ALL tasks that have it open, close it. (man 3 unlink In fact, I'm pretty sure one task can create a file, open it, unlink (rm -- but the name there is wonderfully descriptive -- remove a link (the directory entry) from a file) it, and then write and read temp data to that file...and one can continue to do that until the task exits...look ma, self-cleaning tmp files! I'm pretty sure something like that is happening with you. I was able to reproduce your "problem" easily. I have a little machine here that has a 100MB /tmp, I created a 70MB text file, and tried to edit it with vi. Well...vi quickly discovered it couldn't create its vi.recover file, /tmp showed 100% utilization, but "du" could not show me where the last ~27mb of disk space went. As soon as I exited vi, the space came back. One big clue: since you are hitting 105%, that means the offending process is running as root -- I could only take /tmp to 100% as a non-root user, but if invoked as root, 105% (as expected). So the first lesson is, whatever you are doing, 1G /tmp is not big enough. Probably more scary, though -- you have a root process spewing lots of data into /tmp. I don't normally see that...so I'm inclined to think you are running something incorrectly or "solved a problem" by running it as root. Might be totally legit and just needs more tmp space, but my very first thought is "YOU ARE DOING SOMETHING WRONGLY!" Next time you see this happen, before rebooting, ps -aux and look at all your root processes and kill them one by one until you suddenly see your disk space come back. That was your offender. Nick.
