Adding usable disk to / filesystem

[fg_1]

All

I have been trying to figure a way that I may possibly expand the / filesystem in such a way that it uses additional disk space configured on a seperate area of the system.

I know all too well that the way to expand / is to ignite/rebuild and expand since it is contiguous disk but what I am trying to hash out is if there is a way to say configure another filesystem and then link the 2 filesystems together so that / uses the additional diskspace configured on the 2nd filesystem.

All opinions and suggestions are welcomed here.

Thank you for your support.

fg

[Pete Randall · Accepted solution]

Frank,

Well, you can obviously add the additional disk to vg00. I'm assuming you have particular file systems which need more room. If that's true you could then use the additional space to create a new file system for /var, for instance. Call it /newvar, make it as big as you want /var to be, copy the contents of /var into it, switch the entries in /etc/fstab so that the /newvar's device will be mounted as /var and re-boot.

You should be aware that /, /stand and primary swap areas are location sensitive and need to be contiguous so this won't work for them.

Pete

[fg_1]

Thank you pete, I know / has to be contiguous. The dilema that I am faced with is that I have NO CLUE AT ALL what is filling up the root filesystem, its configured on all of our systems for 160MB (MORE THAN SUFFICIENT) at least one would think so, yet there are some systems that say that the usage is 88% or higher. I have run numerous find commands against it, checked for core files, etc.. etc.. and nothing does the trick, so I was taking a shot in the dark of possibly linking another directory to / so that I can use that additional disk space on /. A shot in the dark at best without rebuilding.

Thanks pete.

[Marco Santerre]

Often what happens in this case is that you might have space used in directories that serves also as mount points. You may want to unmount some of your mount points like /var, /tmp and verify that no space is being used in there. Another option, and I've seen this before, in your /etc, you may have copies of some of your files or directories like lvmconf. I remember seeing a place keeping a copy of lvmconf in /etc

[Pete Randall]

Frank,

I almost added a comment about "why you needed to expand". Have you looked at /dev files? One of the favorite mistakes is to do a backup to /dev/rmt/om (letter "o", rather than numeral "0").

Another one that I got caught on once was junk hidden under a mount point. Say you have a file system called /george and one day /george doesn't get mounted (or gets unmounted) and applications continue to write to /george. All that junk is going directly into the root file system, but the next time /george gets mounted properly, you can't see it. You can check this by unmounting and doing an ll on the mount point - or shut down to single user and check the mount points.

I'm sure there's something out there eating up your space, we just need to find it.

Pete

[Pete Randall]

Frank,

Any luck?

Pete

[fg_1]

None pete. Giving it up for now. Thanks for the assist and ideas.

[Pete Randall]

Frank,

Don't give up! Can you post the output of a du -sk /* and a bdf -l?

Pete

[Dave Wherry]

Frank,
As Pete asked, please give some more information from du and bdf. Don't just mask the problem by adding more space. I had some SAP Admins who always just added space to a problem. They never resolved it. Created some messy systems.

[fg_1]

Sorry guys, didnt mean to give up the ship without a fight, just getting swamped here today.

here is the du -sk /* output, and attached is the bdf output

mmdcux03@/root# du -sk /*
0 /Mail
0 /SD_CDROM
0 /UNIVERSE
1 /_-_No_PrGlOg_-_
0 /bin
0 /cdrom
88 /dev
69230 /etc
444487 /home
5 /lawprod
354 /lawschpc.csv
0 /lib
0 /lost+found
0 /mnt
0 /mnt1
0 /net
1 /nohup.out

[Pete Randall]

Frank,

Compared to mine, your /etc is huge. How about (when you get a chance) doing a du -sk /etc/* and passing that along?

Pete

[Pete Randall]

Frank,

Let's ammend that to be

du -sk /etc/* |sort -n



Pete

[Patrick Wallek]

I agree. /etc seems to be quite large.

Here's /etc from one of my machines.

# du -ks /etc
13077 /etc

[Marco Santerre]

I agree with all the previous answers as well. Check for residual vg config file in your lvmconf directory.

[fg_1]

I agree with both of you that /etc/ is huge, attached is the output.

[Marco Santerre]

From your attachement I see that you have several passwd file which are probably bakcups when you were doing maintenance on them, maybe you can get rid of a couple of them, especially older ones.

[Patrick Wallek]

First thing I'd do is see if I could delete some of the passwd* stuff that's there.

The next think to take a look at is your /etc/lp directory. That appears to be the main culprit.

[Pete Randall]

Frank,

Looks like the lp interface is full of print jobs. What do you see when you do an lpstat?
And, out of curiosity, do a du -sk /etc/lp/*

Pete

[Jochen Heuer]

Hello,

to find the big directories in /etc run

$ find /etc -type d -exec du -sk {} \; | sort -n

then have a look at the biggest dirs (which are printed last)

If you want to check for biggest files in /etc just run

$ find /etc -type f -exec du -sk {} \; | sort -n

Have fun and watch out for too much / big print jobs ...

[fg_1]

Here is the output from du -sk /etc/lp/*

mmdcux03@/root# du -sk /etc/lp/*
0 /etc/lp/cinterface
0 /etc/lp/class
0 /etc/lp/info
41944 /etc/lp/interface
286 /etc/lp/member
0 /etc/lp/sinterface


Just for ha ha's i am attaching a du -sk from
the /etc/lp/interface directory.

[Marco Santerre]

I do assume that these are all printers that are currently defined and used on your system, right?

[Pete Randall]

Frank,

What's the model.orig for? Does lpstat show anything queued for that? Is that a legitimate print destination?


Pete

[fg_1]

As far as i remember, the /etc/lp/interface/model.orig directory is created when you use jetdirect printer installer for hpux which is what we use.

[Pete Randall]

Frank,

Since I don't use printer installer, I can't vouch for that - but it's HUGE!!!! Do a more on it. What the heck is in it? I would hope you could blow it away or at least trim it somehow.

Pete

[Marco Santerre]

Pete, you can't really trim as it is a script file that is used by Jetdirect. So unless, you have unused printers I don't think it is possible to reduce this directory. Unless maybe a newer version of Jetdirect fixes this.