Solaris

Did you find out what was using all the space? Your plan to just move /var and hope for the best puts you in a worse position in my opinion.

if you can work out what space is used then perhaps we can discuss a reason and an action plan to suit. If you run du -ksx / and the space used does not tally with the output from df -k then there is a good chance that a directory with content has been over-mounted with a filesystem and the content is now inaccessible, but of course still costing space.

Can you show us the output from the two commands? The du will take quite a while to run.



Kind regards,
Robin

Thanks for the reply,i have provided below the output for df -k and du -ksx /

Code:

 # df -k
Filesystem           1024-blocks        Used   Available Capacity  Mounted on
/dev/md/dsk/d0          10327372     9833243      390856    97%    /

Code:

 # du -ksx /
9821458

---------- Post updated at 07:24 PM ---------- Previous update was at 07:21 PM ----------

I looked at the space utilization as well, many java oracle and other development applications are using the space and looks like we will not be able to delete anything.Thanks for your help

Okay, so it looks like you don't have the problem I considered.

Does the output from du -kx / | sort -n give you clues as to where all the space is being used?

Is the output from df complete? If all the applications and data are in other filesystems, that is good and it might just be that the root filesystem allocation is too small.


Have you considered all the suggestions in the thread, such as in posts 3 & 9?

I'm still not clear if the filesystem in within LVM (or equivalent) or not. It looks like you might have a simple slice of disk and that may be difficult to work with. What else is on the LUN?

Can we have the output from the various displays to see what has been allocated? We can then consider what is the best way for you to progress.



Kind regards,
Robin

These applications are likely not part of the operating system. It is well possible they allow their logs and/or data to be relocated elsewhere. If you don't find how to do it, you might also use loopback mounts to remap the directories using a lot of disk space to directories located on the new file system (new LUN). Note that you might have SVM mirroring in place with the current setup (run the "metastat" command to check it) and you'll lose that feature if your new LUN isn't already on a mirror.