How to increase free space on /tmp using JFS?

[Gino Castoldi_2]

Hi,

HPUX 11.11 JFS vg00 is mirrored

We want to increase disk space on the /tmp
file system in the vg00 volume group.

I believe we need to boot the server into single user mode so we can umount the /tmp
file system. What are the exact steps to increasing free disk space?

10 points to any answer.
Thank you
Gino

[Pete Randall · Accepted solution]

Gino,

If you have OnlineJFS, it's simple and you don't need to reboot. Check like this

# swlist |grep -i online
B3929CA B.11.11 HP OnLineJFS
OnlineJFS B.11.11.03.03 Online features of the Vx
FS File System


If the above shows you have OnlineJFS you can expand by running "fsadm -b newsize mount_point". Have a look at "man fsadm_vxfs" for details.

If you don't have online JFS, then you have to run lvextend and extendfs, which requires the FS to be unmounted, probably necessitating a reboot to single user mode. Look at "man lvextend", particularly the EXAMPLES section.


Pete

[A. Clay Stephenson]

Although it isn't the question you asked, you probably aren't asking the right question. The right question is why do you need to increase space on /tmp? On modern UNIX boxes (those less than about 15 years old), /tmp should only be used for temporary files directly associated with the OS. User temporary files should use /var/tmp and well-written applications (including scripts) will go a step further and query the TMPDIR environment variable and use that if defined and default to /var/tmp otherwise. Only on very rare occasions does /tmp itself need to be enlarged.

[Geoff Wild]

Sorry Pete - you forgot to say you must lvextend prior to doing the fsadm command:

If /tmp is /dev/vg00/lvol6

then

lvextend -L 1024 /dev/vg00/lvol6
fsadm -b 1024M /tmp

Rgds...Geoff

[Gino Castoldi_2]

Clay,

I agree with you about the general/normal use of the /tmp fs. However I have a specific/special reason for enlarging /tmp

Our /tmp is currently 7GB and I want to increase it to 14GB. The reason is that we are running OVO/UX on this server (clustered) and we want to run the OVOU backup utility (opc_backup) which copies
several file systems and Oracle database files to disk and the best candidate for this is the /tmp filesystem.

We really need a spare disk for this purpose
but for now this is the best we can do.

10 points to any answer.
Thank you
Gino

[Geoff Wild]

I wouldn't use /tmp for copying OVO db's and file systems - I would create a new file system for that purpose....

Something like /data/openview/backup or /data/openview/tmp

(that's what we do)

Rgds...Geoff

[A. Clay Stephenson]

Mine is set up as /ovobackups and I also have a separate /download filesystem which is used to archive the OV/O history logs. My /ovobackups filesystem is sized large enough to handle the most recent 2 backups. This directory is backed up by Data Protector and a cron job runs to only keep the 2 most recent versions. Older backups can be restored by DP. In any event, OV/O is considered an application and /tmp should not be used. 7GiB is an enormous /tmp filesystem. By comparison, /tmp on my largest boxes is 512MiB and stays at 1% utilization almost all the time.

[Ivan Krastev]

You can increase /tmp very easy:

If you have OnlineJfs installed:

#lvextend -L 14436 /dev/vg00/lvolX (see output from bdf, where /tmp is located)

#fsadm -F vxfs -b 14680064 /tmp


If don't have OnlineJFS:

Check what process use /tmp with fuser and try to unmount it.

#umount /dev/vg00/lvolX

Do same as above - lvextend
#lvextend -L 14436 /dev/vg00/lvolX
#extendfs -F vxfs /dev/vg00/rlvolX

Mount agains:
#mount /dev/vg00/lvolX /tmp

If /tmp cannot be unmounted you should go to single user mode.


regards,
ivan

[Gino Castoldi_2]

Hi,

Is it possbile to "reduce" the /tmp file system at a later date?

10 points to any answer.
Thank you
Gino

[James R. Ferguson]

Hi Gino:

> Is it possbile to "reduce" the /tmp file system at a later date?

Yes, if you have OnlineJFS you can not only extend but you can reduce the size of a filesystem without having to recreate it.

The later the version of JFS the better.

Regards!

...JRF...

[Geoff Wild]

Reduce - yes - I have never had an issue.

Make sure /tmp is cleaned up as much as possible...

The defrag it:

fsadm -F vxfs -d -D -e -E /tmp

Then reduce the filesystem first:

fasdm /b 512M /tmp

The the lvol:

lvreduce -L 512 /dev/vg00/lvol6

Rgds...Geoff

[Bill Hassell]

Using /tmp in this manner (multiple GB of critical files) is asking for a really big problem. As implied by the name, it is a TEMPORARY directory and you will find in the /etc/rc.config.d directory an option to erase the /tmp direcory every time you boot up. /tmp and /var/tmp MUST be assumed to be unstable! The reason is that the permissions grant any user the privilege of filling the directory or worse, remove any file at any time.

So create a separate lvol immediately and as Stephen suggested, create a special mountpoint with the correct (protected) permissions and ownership. Transfer the production files to this directory and then backup what is left. Then try reducing the lvol. Most lvol reductions will fail with filesystem corruption and will need to be newfs'ed and the data restored. Sometimes fsadm can reduce a filesystem successfully but with such massively large files (and the busy nature of /tmp), removing them will likely leave the filesystem fragmented, a key to corruption with reduction.