/tmp filling up problems

[Glenn Mitchell_2]

My /tmp file is slowly filling up and my ROOT filesystem is at 84% now despite trimming efforts. There are hundreds of <1K files associated with our manufacturing database that are a few weeks old. My ax is poised above many of them but before I do something rash, I'll backup the files to another volume; And I want to advise the DBAs about how these small files add up to cause troubles. How do you find the block size of the ROOT filesystem? It is not in my configurable parameters (bsize?).

Thank you for your help.

[erics_1]

Glenn,

fstyp -v /dev/vg00/lvol1

f_frsize=8192

f_bsize is the default value

Regards,
Eric

[Pete Randall]

Glenn,

From Robert-Jan's response in this thread, I believe your block size is most likely 1024K:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=866780

Not sure how you'd check it, though.

As far as your /tmp filling up, I would set up a nightly cron job to clean every thing older than so many days:

01 01 * * 01 /usr/bin/find /tmp -type f -mtime +10 -exec rm {} \;


Pete

[Glenn Mitchell_2]

Which value am I looking for? If the DBAs save a bunch of files that are 93 bytes big, does this mean that each file is taking up 8 Kbytes of real estate (!)?
For my / filesystem:
# fstyp -v /dev/vg00/lvol3
vxfs
version: 3
f_bsize: 8192
f_frsize: 1024
f_blocks: 143360
f_bfree: 23970
f_bavail: 22728
f_files: 9864
f_ffree: 5992
f_favail: 5992
f_fsid: 1073741827
f_basetype: vxfs
f_namemax: 254
f_magic: a501fcf5
f_featurebits: 0
f_flag: 0
f_fsindex: 7
f_size: 143360

[erics_1]

Glenn,

The f_frsize is the actual blocksize of the filesystem. In your case 1024.

Regards,
Eric

[lawrenzo_1]

Hello,

you should find out what is creating these files, are they log files or data files?

Ideally though you should think about creating a new filesystem and mounting /tmp on it as this will prevent root filling up to 100% which will cause numerous system problems/

Lawzo

[Glenn Mitchell_2]

Thank you all for your help. Please close this thread. The DBAs are checking the files to determine what script is creating them - with an eye for saving them to one of the DB volumes instead of /tmp. There are a few log files with sizes around 2 MB, whose location will be evaluated.

[Bill Hassell]

Several things:

/tmp is not for use by applications. The correct location (for the last 10 years or so) is /var/tmp.

/tmp is not normally part of the root filesystem. If you type bdf /tmp, does it report /tmp or just / at the end of the line?

The / filesystem is static and only root user can write to it. So if the DBAs have root privileges, take it away. Then analyze / using du:

du -kx / | sort -rn | head -20

This will show the biggest directories at the top. The largest directories will be /sbin and /etc. Anything else is a problem. The root filesystem doesn't change size.

The blocksize does not control the minimum storage size, it is the frag size. However, today's disks are so big, worrying about hundreds of small files is unimportant. You find the largest directories first, then look in those directories to see why they are so big.

Post the above du list and we can probably find the problem very quickly.

[Devender Khatana]

Hi Glenn,

->Thank you all for your help. Please close this thread.

It is not advised to close threads untill your problem is resolved.

Moreover, threads open by you can be closed by you. When you see your own threads having logged in to itrc, it will provide you the option of closing the thread. It is also advised to assign points to all the replies according to relevance while closing the thread. The option to assign points is also available when you view your own threads.

HTH,
Devender

[Wodisch]

Hi Glenn,

to add that detail about how much space is occupied by one of those small files:
- your file system block size is really 1024 byte/block (fr_size)
- the VxFS allocates 8 blocks by default to each to each new files - that makes 8KB/per file, even though only one block is currently used
- be careful about hundreds or even thousands of files within one directory: UN*X reads and writes directories always completly. So, if your directory's size if bigger than a few KB, this will slow down your system!

FWIW,
Wodisch

[Glenn Mitchell_2]

Our DBAs have done some trimming to the /tmp directory and brought it down to 23% full. But they have not yet done anything about the 700+ small files. I have informed them that the 53K directory size is probably degrading system performance. They are currently looking into where these files are being generated from, how long they need to be retained for, where they should be relocated to, and determining how/when to trim them down to a reasonable number.

Thank you for your advice.

[Kent Ostby]

One other thing that I do from time to time is look at my last reboot.

Let's say last reboot was in November, I'll do something like:

pwd (to make sure I'm in the right directory)

ll | grep -v -e Nov -e Dec -e Jan -e Feb -e Mar -e May -e Apr > useme

awk -f '{print "rm -r ",$NF}' < useme > useme2

chmod +x useme2

./useme2

I use this especially when a lot of the stuff is old vi temp files.

[Glenn Mitchell_2]

Thank you all for your help.