/tmp on vg01?

[W. Michael King]

vg00 is 2x 9GB drives and totally full
vg01 is 4x 18GB with plenty of space on them

Any reason I can't move /tmp to vg01?

My tmp is somewhat large (necessary because of the database being used) but is mostly empty most of the time.

If tmp can't go to vg01, then I'm stuck with having to re-activate a couple of 4GB'ers which I'm told are not going unsupported. I've got 3 so, I'd have a spare but I'd rather not use them.

[W. Michael King]

Just FYI -

everything is mirrored.

[Karthik S S]

You can move /tmp to vg01. Not a problem at all.

1. Create a LV on VG01 with sufficient space that you need.
2. Edit /etc/fstab so that it contains /tmp pointing to the new LV.
3. Reboot the machine.

-Karthik S S

[Steven E. Protter]

You can do it. For some reason it makes me uncomfortable.

In your shoes, I'd consider moving something else.

The reason is that if for some reason vg01 needs to be deactivated, your system will essential have to be shut down.

Many databases and application programs need to use the /tmp area to store various temporary files, hence the name.

You CAN do it, but you need to be aware of the potential consequences.

I won't say its the gospel but a lot of shops follow the standard practice of keeping the core OS and all filesystems for booting in vg00 and putting other things like oracle data and the like in subsequent volume groups.

I apologize if I seem preachy, I'm just presenting a point of view and hope you understand.

Summary: Yes, though I would not do it.

SEP

[W. Michael King]

It was making me a little uncomfortable as well... thus the post here.

But if vg01 goes offline, we're dead in the water anyway. So that part doesn't bother me that much. I was more worried the ramifications, should I have a problem at boot.

[Rajeev Shukla]

No you wont have any problems at boot, beacuse boot the VG will be activated and mounted simultaneously. But why dont you add more disk to your VG00, because maybe in long run you might need to extend other filesystems in VG00 as well.

Cheers
Rajeev

[Bill Hassell · Accepted solution]

Technically, you always have /tmp available. Before /tmp is mounted from vg01, the mountpoint /tmp is just a plain directory and although it resides on the vg00 disks, it still functions as an ordinary directory until overlaid by mount /tmp. So no problem in moving /tmp. I will second the idea that 9Gb is way more than needed for HP-UX on vg00. Most likely, someone decided to put some non-HP-UX directories/files on vg00.

[Con O'Kelly]

One suggestion is that if possible create a separate tmp fileystem (eg /application/tmp) for the application that requires huge amounts of /tmp space.

Many applications default to using /tmp or /var/tmp but some can be set to use a different filesystem (directory).
The benefit is that if it fills its own tmp space it won't impact on other applications that use /tmp.

Most applications don't utilise huge amounts of tmp space so using /tmp is completely normal for them.

Cheers
Con

[W. Michael King]

Hadn't thought about the fact that /tmp would still be there even if the vg01 /tmp lv didn't mount. Just wasn't thinking in that manner. That makes me a little less nervous about moving it.

Yeah 9GB should be enough. As I pointed out, /tmp is mostly unused the vast majority of the time (99%+). The way our application works there are some times when it needs the space (complicated selects mostly). They will fail if it doesn't have enough space, and the app crashes(fortunately just for that 1 user). And really I need to extend it even more. That's part of why I'd like to get that space back on vg00 for other uses. Most of the time it's doing nothing! And I have plenty of space elsewhere.

I hadn't thought about looking into whether the database can use some other spot for it's temp space. That may be the best answer of all. I'm going to have to look into that.

[Pete Randall]

Robert,

I'll just throw this in to see if it does anything for you:

Most apps allow you to set the location of temporary space in an environmental variable. I would check carefully that this isn't the case here before I bothered.


Pete

[W. Michael King]

>But why dont you add more disk to your VG00, because maybe in long run you might need to extend other filesystems in VG00 as well.


I'd love to add more disks. All I have on hand not in use are 3x 4GB drives. I'm told they are unsupported. Which with the spare I don't mind too much.

Unfortunately, I can't buy more without it being "unbudgeted capital". That's not a good thing. I asked for more space for next year, but it'll be a while before I hear back about it.

[Jeff Schussele]

Hi Robert,

/tmp should NEVER be used for apps to place *large* temp files - absolutely the wrong place to do this.
As mentioned I'd give them another FS & dir & have them set another $TMP or $TMP_DIR variable - or whatever the app uses. If they can't or if the app is written to /tmp explicitly, then that's damn shoddy coding & should be corrected - instead of a bandaid solution of making /tmp huge. /tmp is supposed to be available for EVERY user and having an app monopolize it with ridiculously large temp files is not playing fairly nor by the rules. Fix the problem & not the symptom, I say

My $0.02,
Jeff

[W. Michael King]

We have a winner!

By default the db uses /tmp. However it can be changed. The app needs to be stopped and started for it to take effect. And then I can decrease /tmp to a reasonable size...

Guess I know what I'll be doing next downtime.

Thanks everyone - points coming y'all's way shortly.