Hello All,
I have solaris server running,
uname -a
SunOS host 5.9 Generic_112233-12 sun4u sparc SUNW,Sun-Fire-280R
Filesystem Size Used Available Capacity Mounted on
/dev/md/dsk/d0 9.8G 8.7G 1.0G 90% /
/dev/dsk/c1t1d0s3 4.3G 7.7M 4.2G 1% /tmp
I want to increase my root by 2GB more by consuming the space in /tmp
How can i do that? can anyone help . Also kindly help me with the commands.Thanks.
You can't, as the two file systems are on different disks. Even if they were on the same disk, it would be a risky task that should be reserved to experienced people.
What you can do, though, is redesign the file system tree by e.g. moving a large "branch" to the second disk, freeing its space on disk 1, create a tmp directory within that "branch", and then link /tmp thereto. You'll have to modify /etc/fstab accordingly, and make pretty sure that during boot the FS is available before any of its files are needed.
I would actually ask the reverse question:-
"What is filling up my root filesystem?"
You might help to answer this reviewing the output from the following:-
cd /
du -ks *|sort -n
You can then work down the largest directories to get a feel for where the space is used. Perhaps you can move these.
Are you using a volume manager at all on this server (Veritas perhaps?) You would be far better to try to split up and shrink the root filesystem to hold just the OS that you need to boot. Data in the root filesystem, whatever directory path you squirrel it away under, is usually bad as if your application runs away, you can end up with a system that will not boot.
I would suggest that splitting out /var (where most OS logs are written to, along with mail files etc.) /home (user personal files) and /tmp would be good practice.
Can you tell us more about the server disk you have?
Output from df -h and a listing from the volume manager of all the volume groups would be useful. That might be a vgdisplay -v or vxdg list & vxdg free
That said, splitting a root filesystem is not a trivial matter. You will probably have to boot to single-user from media so that it is not in use, then move data around before attempting a shrink if your volume manager allows it.
How critical is the server and it's data? It would be prudent to check you can read your backups before starting anything.
Robin
While I agree expanding the file system would be a risky and unrecommended task for unexperienced people, there is actually no evidence / and /tmp are on different disks, more precisely, we do not know from which underlying devices the metadevice used by the root file system is made of but it is probably a mirror with one of its component on the same disk as /tmp. However, the standard layout is locating /tmp immediately before / while for growfs to be possible, it should have been located immediately after /. The bottom line is you probably can't expand / with /tmp but it might be possible to grow / by cannibalizing another file system like /export/home.
Thanks for all the help.I asked the team to provision a 20 GB new LUN to the server.Can we expand the / by using the new LUN?
No. The root file system can only be expanded using contiguous space from the same disk.
Hi,
it seems that ncdu is available too for SunOS. A good menu-driven program for checking used space on your system.
regards,
s.
Did you find out what was using all the space? Your plan to just grow it puts you in a worse position in my opinion.
How do you plan to recover if there is a critical failure? Perhaps a hardware error (even if it's virtual) or some sort of corruption? With all your data in / then you are having the root filesystem open and active nearly all the time. Even an unexpected shutdown (e.g. power loss) could leave you needing to fsck which for such a huge / will take a long time and if it doesn't work then you have lost your server.
I would strongly recommend thinking about splitting up the root filesystem to hold just the critical OS and keeping anything not needed for the boot on other filesystems.
Robin
You can use "live upgrade" to create a new disk layout on a second disk (looks like you already have a mirror running, just take the second half of the mirror) and move your system to the second disk. All you need is one reboot to boot in to the new system. After that, you can use the old disk as second half of the mirror.
Beginners guide to Oracle Solaris Live Upgrade
There is more documentation about that matter on the Oracle site.
What is the problem with root (/) ?
Why do you need to expand it ?
Can it be achieved with other methods (new mountpoint, symlink or similar) ?
Services on the machine should be separated from system partitions for various reasons, one being to simplify future configuration changes and needs.
This is not required, but i consider it good practice.
So, change the service in question if you can, take a look what is taking up space and what is that space needed for in root(/)
Hope that helps
Regards
Peasant.
Thanks for all the replies.
So i asked the team to provision 20 GB LUN , can i move /var from / to te newly provisioned LUN?
If yes, how will i be able to do it ? Should i boot from a LIVE CD and do it ? we dont have a solaris OS CD as of now .Is there any other alternatives to do it.Thanks again for all the help
What about answering to the questions asked by the various people that tried to help you instead of insisting to go a way that is more that likely doomed, given the fact you looks to have not enough experience and skills to achieve it?
Hello All,
I tried to look at clearing space , cleared all logs and crash dump files ,And looks like i will not be able to delete anything further.
I tried talking to my peer and he says that we will not be able to delete anything .
Should i try the method i posted earlier?Thanks for any help
So you have a server that presumably had no disk space issues during more than a decade and suddenly there is not enough space in the root file system. How do you explain that?
What do you need that space for?
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 /
# df -k
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/md/dsk/d0 10327372 9833243 390856 97% /
# 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.