Hello,

I ran out of space on the VAR file system.

The VAR file system isn't the last one on the disk and there is plenty of space on the rest of hard drive and it was allocated when I the extended partition.

Is there anyway to move the file systems that follow VAR down, then leave free space just after VAR and expand it?

Won't I have to unmount the VAR file system and the rest of the file systems before they are moved...providing they can be moved?

Windows has Partition Magic is there any such thing for Linux.

Suse 11.0

Thanks

parted magic or systemrescue cd, and symlinks should be enough

Do you mean there is actually space left on the device (eg, /dev/sda1) with /var on it? If so, you have not really run out of space. Who/what told you this?

But I presume you mean that the partition is full but you could add another partition on the hard drive. If so, you could make another partition, move /var into it, create an empty /var as a mount point in your root filesystem, and add something like this to /etc/fstab, if the new partition is /dev/hda3:

Then at boot time that partition will automatically be mounted on /var.

Note that the OP is using CentOS under VMWare running on an XP system. That's a configuration that may impose additional restrictions on file and partition management, and I'd expect that "standard" replies related to /dec/sda and 'partitions" need to factor in the VMWare restraints.

That being said, I haven't a clue as to what the OP meant by "the VAR file system," nor anything about VMWare.

Thanks MK27.

A DF -K noted that /var was 100% full.

I like your idea of how to fix this problem.

I have these questions, how can I create a second /var partition (empty space on the same physical drive, like you said). Do I need to unmount the filled up partition?

How can I copy the data from one /var to another /var both with the same name.

Can be more specific with some details please.

Thanks again...

Why go through the effort and aggravation of having a separate /var partition in the first place? Put it all (/home, /etc, /everything) under "/" and have done with it.

I agree with QuakeBoy2 and think you should have a look in /var first.

/var/log contains the system logs, like messages, that can get very big over time if you don't occasionally trim them. You probably have a few monster logs in there. How big is the partition?

Anyway, you are obviously close to overstuffing the thing anyway. You can expand your filesystem in the manner I describe by choosing a directory to move out for fstab mounting. /usr/local is a more normal choice, but if you want to use /var I think it should be fine. Just make sure it is set up to automount as I described! There are some directories you should not do this with, notably /lib and /sbin.

You can add a partition with fdisk. You should try and figure out how to do this yourself, tho, by reading the man page and asking questions, because obviously you can ruin everything if you are not clear about what you are doing (there are some graphical tools for this that I'm unfamiliar with which you might prefer).

Once you have a new ext3 partition, create a temporary mount point for it and try to mount it (let's say this is /dev/hda3):

If it doesn't mount, you didn't create a valid ext3 partition. If it did, everything is fine.

Now you just copy the contents of /var into /mnt/tmp. Don't do it so you end up with a /mnt/tmp/var, do it so that /mnt/tmp looks exactly like /var. Follow?

Then you can ADD THAT LINE TO FSTAB, erase /var, and reboot immediately. I'm presuming that you are actually using a normal Suse installation and not that thing PTrenholme mentioned. Be careful!

There is no good reason for /var to ever fill up anyway. Pruning the logs is a good place to start, but likely isn't the biggest problem. You should take a look in cache, particularly in the mail cache, to see if you have a directory that is just getting bigger and bigger and bigger.

Could be you have an error message being emailed to someone every couple of minutes but your mail transfer agent is not properly configured, so those messages are piling up in the outgoing mail queue. I have seen literally millions of files accumulate in that queue under these conditions, taking up gigabytes of hard drive space.

For workstations that is fine, but for a server, you want separate partitons that need to be mounted with different attributes. For example, /tmp and /var/tmp should be mounted with the noexec,nodev options. On some filesystems, you want to include quota support. Some partitions should be mounted read-only. On a workstation, the /home and /usr partitions will be the largest, you having a separate /home partition makes sense, allowing you to reinstall or install a different distro, but preserving your personal files. On a server, the /srv may be the largest, and the /home directory relatively unimportant.

I would first look at /var/log/ and check if there are a lot of archived logs that can be moved to backup or deleted. If it is a mail server, do you have a user with GBs of mail? Maybe you want to enforce quotas.

However, since the OP is running CentOS under VMWare, your advice is this case may be best. The OP's capitalization of /var distracted me from some details, wondering if it was an acronym instead of the /var directory.

Most likely we have run out of space on the partition and the first time it was noticed was when something went to write to /var.

So probably swamprat does need to reorganize his/her filesystem, but not necessarily by moving /var, which is what I was trying to hint at by saying there may be a (larger) and more appropriate directory, like /usr/local or (best idea) even /usr itself, since /usr is never suppose to contain files needed prior to fstab mounting.

In fact, the original purpose of the /usr directory in the *nix filesystem hierarchy was to permit a filesystem to be split across devices in the manner I've described.

/var is not supposed to be a subdirectory of anything other than "/". If it's too small it needs to be expanded: either by making the partition larger or moving it to "/". If you are trying to say that it should somehow be linked out of /usr or anything else, then that is wrong.

Thanks again MK27.
Been tied up with the day job for the last few days but back to this issue now.

As you can see from the information I pasted in below I named the new partition "varnew".
I did the copy as you indicated and that worked without an issue also.
Now I'm ready to do the fstab thing and I need some more information and hand holding with this as I'm a newbie and I don't want to kill the whole system. The FSTAB is posted below also.

As you can see when I executed the mount command it must have placed the information about the new filesystem in the FSTAB member.

Now I'm not sure what to do next. I really want to rename varnew to var...if possible and get ride of the old VAR partition.

Can I just delete the old VAR partition, do a MV VARNEW VAR? Fix the line with /dev/sda11 to VAR and the reboot? Will that do the trick?

If not how would I go about resolving this.

Thanks all and Happy New Year.


vuquestmain:/ # df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 608756 331988 245844 58% /
udev 133584 136 133448 1% /dev
/dev/sda3 62217 17760 41244 31% /boot
/dev/sda7 311123 147664 147396 51% /home
/dev/sda9 2071384 68960 1897200 4% /opt
/dev/sda10 497829 31808 440319 7% /srv
/dev/sda6 209998 55185 143971 28% /tmp
/dev/sda8 5676464 3605216 1782884 67% /usr
/dev/sda5 311123 299236 0 100% /var
/dev/sda11 798476 312580 445336 42% /varnew
vuquestmain:/ # cd varnew
vuquestmain:/varnew # ls
adm games lock lost+found opt spool usermin X11R6
cache lib log mail run tmp webmin yp
vuquestmain:/varnew #

/dev/sda1 swap swap defaults 0 0
/dev/sda2 / ext3 acl,user_xattr 1 1
/dev/sda3 /boot ext3 acl,user_xattr 1 2
/dev/sda7 /home ext3 acl,user_xattr 1 2
/dev/sda9 /opt ext3 acl,user_xattr 1 2
/dev/sda10 /srv ext3 acl,user_xattr 1 2
/dev/sda6 /tmp ext3 acl,user_xattr 1 2
/dev/sda8 /usr ext3 acl,user_xattr 1 2
/dev/sda5 /var ext3 acl,user_xattr 1 2
proc /proc proc defaults 0 0
sysfs /sys sysfs noauto 0 0
debugfs /sys/kernel/debug debugfs noauto 0 0
usbfs /proc/bus/usb usbfs noauto 0 0
devpts /dev/pts devpts mode=0620,gid=5 0 0
/dev/sda11 /varnew ext3 acl,user_xattr 1 2