Filespace issues

[Betty Fessler]

I have some very old HP-UX.B.10.20 fileservers that have been turned over to me to administer and they have very limited filespace available for patching/upgrades. Has anybody had any issues linking /usr/share to another filesystem with more space. I know that /usr/share/man can be NFS mounted without problems but I need more space then that, so I'm thinking of linking the entire share directory to another filesystem location.

[RAC_1 · Accepted solution]

There should not be any problems.
If you are going to have seperate FS for it, you will have to prepeare a hard link.

[Tim Nelson]

you can mount an entire filesystem at /usr/share or /usr/share/man .

Before patching I always cleanup the formatted man pages (not the nroff pages) to make sure I get the updated ones.

rm /usr/share/man/cat*.Z/*

While you are on the subject of patching. I have also done a trick many times to temporarily make room in /var/adm/sw. Create a new filesystem, copy everything from /var/adm/sw to the new. remove files from /var/adm/sw, mount the new fs at /var/adm/sw, update patches, cleanup patches, unmount new FS and copy back to /var/adm/sw ( sounds like a lot of work but the saved patches take a huge amount of space, once one set is committed you get the space back)

[Betty Fessler]

No its not a seperate filesystem by itself but it is on a seperate filesystem, I just copied the /usr/share directory to another filesystem. Then moved /usr/share to /usr/share.sav then did a ln -s /newfilesystem/share /usr/share. If there's not a problem with that then I'll remove /usr/share. Do I need to hard link it? It's working for man pages.

[DCE]

I beleive in 10.20 there is a -F parameter to the cleanup command.

cleanup -F

This will Force commitment for all patches currently applied to the system, and remove all of the backout files. This should free up space on the system. If you want to be conservative, run the cleanup command without any parameters.

[Betty Fessler]

I've already removed the cat.* stuff and didn't gain enough space. I've done a cleanup -F and /var should be fine. This system has been stable for years but has never been updated or patched and now due to security issues I've been required to patch the system. Unfortunately as you can see there's very limited space,
83733 18962 56397 25% /
47829 17380 25666 40% /stand
153613 44128 94123 32% /var
355029 285813 33713 89% /usr
30597 5224 22313 19% /tmp
271157 206681 37360 85% /opt
There is however another filesystem for a
database that has plenty of space and that's where I moved the "share" directory. For the
larger patch bundles I'm NFS mounting them from another system and other I'll temporarily store on the db filesystem.

[DCE]

I assume /opt is one of your problem mount points. Change to /opt and run the command

du -sk *

This will give you the amount of space being consumed by the subdirectories under /opt. If there is a directory that is large, and not neccesary for booting the system, create a new lv of the appropriate size, move the data to it and mount it on the appropriate name.

[Betty Fessler]

I believe I understand RAC's advice and will go with the linked /usr/share. Thanks everyone.