On Fri, Jan 23, 2015 at 2:53 PM, Ingo Schwarze <schwa...@usta.de> wrote:
> Hi Predrag, > > Predrag Punosevac wrote on Fri, Jan 23, 2015 at 03:24:00PM -0500: > > > I was following this discussion with the great interest but without > > intend to participate in it until today. > > > > Namely one of my OpenBSD servers (5.6 sparc64) runs Mollify and last > > night I received an e-mail from an angry user who could not upload files > > (the upload will fail or upload the file with file size zero). After > > running df I noticed that /tmp was 100% full (4GB used) but the size of > > individual files was only 12Kb. > > That is unlikely to be due to softdep. The usual reason for a file > system to be actually full and seemingly almost empty at the same > time is somebody doing the following sequence of operations: > > - open(2) a file for writing > - writing a lot of data until the file system is full > - unlink(2) the file > - keep the process running that open(2)'ed it > - let that process keep the file open and *not* close(2) it > > Specifically, in /tmp, anybody can do that. > > > I thought for a second and I remember seeing this with HAMMER on DF. > > The above works with almost any file system. > > > Long story short I checked /etc/fstab and > > sure enough I had rw,softdep next to each partition including tmp. I > > removed softdep rebooted the sytem and /tmp usage dropped to 0%. > > That's not likely to be related to softdep either. Chances are > just rebooting would have solved the issue as well - simply because > rebooting terminates all running processes, and consequently closes > all open files. > One more point to add to Ingo's detailed and very helpful reply. Reboot actually clears /tmp. > > What you should have done instead was run fstat(1), look for processes > having files open in /tmp, use ls(1) -iRa /tmp to find the inode > numbers of linked files in /tmp, and kill the processes having files > open that were *not* linked until you found the one having the big > file open - and then have a friendly talk with the responsible user, > if any, or figure out what went wrong in case some daemon process > caused the issue. > > > My questions is which partitions should be mounted with softdep > > option? > > I'm not an expert on that and hardly ever use softdep, but i'd say > on file systems where file create/delete performance is *critically* > important, performace has been clearly demonstrated to be insufficient > without softdep, and you consider data loss harmless. > > > Is there a way to prune metadata which will save me for problems like > > the one I encountered last night. > > I'm not convinced that's a good question to ask. > > Yours, > Ingo
