2

My disk space on the / partition is very limited. As there are other partitions available I'd like to move /var to /differentPartition/var.

The simplest solution coming to mind is just moving the current files and linking to the new directory. However, I'm not really sure if that's a good idea and if it is as simple as that... Am I about to break my system?

P.S: SUSE Linux Enterprise Server 11 SP1 (x86_64); Linux version 2.6.32.43-0.4-default (geeko@buildhost) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP 2011-07-14 14:47:44 +0200

Edit:

# cat etc/fstab

devpts  /dev/pts          devpts  mode=0620,gid=5 0 0
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
/dev/sda1 /               ext3    defaults        1 1

I was confused not to see my other disk here. The OS is running in a virtual box, though, and I figure virtual hard drives are treated differently than "normal" disks?

So to clarify things, I'd like to move /var to a virtual hard drive...

Edit 2:

# mount

/dev/sda1 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
devtmpfs on /dev type devtmpfs (rw,relatime,mode=0755,nr_inodes=0,mode=755,size=27g)
tmpfs on /dev/shm type tmpfs (rw,mode=1777)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
securityfs on /sys/kernel/security type securityfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
Sildoreth
  • 1,884
fsperrle
  • 495
  • if you have others partition why just not mak /var a mount point on one of the partition ? – Kiwy Feb 28 '14 at 11:06
  • I'm not sure how to do that - maybe it's important to mention that the other partition already has data and var should just be another folder there. So I can't just move the content of var there and mount the folder to /var, right? – fsperrle Feb 28 '14 at 11:39
  • I'm not sure to understand what you mean. could you [edit] your question to add thecontent of /etc/fstab – Kiwy Feb 28 '14 at 11:41
  • From the OS point of view, there is no difference between a virtual disk and a "normal" disk - it is just a disk that is available for use, that's all. Could you add the output from "mount" to the question, too? – Jenny D Feb 28 '14 at 11:57
  • Done. What I did earlier already was move /tmp to the virtual disk and symlink it from /tmp. Is that an option for /var, too? – fsperrle Feb 28 '14 at 12:03

2 Answers2

2

I'm not really saying that moving /var is impossible, but it might be problematic and if you are not that experienced (judging from your 1st comment above) I wouldn't like to advise you over this forum to do it.

The problem, is that /var/log has files (kernel.log for example) opened very early during the boot sequence so you run the risk of mounting on top of a directory where there are files already opened. The system will still work, but you would not be able to see the real log or it will flip when reopened to the new mounted partition, suffice to say, knickers in a twist and core melt down, (you!, not the machine).

If I did it I would attempt to do it as cleanly as possible without adding further complexities such as, making /var as a symbolic line to a folder, under a different mounted partition. Has that been mounted yet ? Durh, I dont know.

A better option would be to look at the directories immediately below /var. Work out where the space is be used.

Possible candidates, /var/srv /var/www /var/mail /var/spool I regard these as secondary (application) type directories, move these to a new directory on your 2nd partition, since the applications that use these generally start later during the boot sequence (after mounting fstabs).

And look elsewhere.

At root the root level, /usr /home /opt are also candidates for moving onto a separate partition.

Finally, since this is a vm, you could opt to expand the fs it uses ?

X Tian
  • 10,463
  • 2
    "Has that been mounted yet ? Durh, I dont know." - thanks a lot for that. Made me take a proper look at the mount output I pasted here earlier. The partition was in fact not mounted. This caused my script to just create a folder an fill up the disk space. The partition is now mounted, freeing up space under / and making the movement obsolete. – fsperrle Feb 28 '14 at 14:04
  • tks, I was a little concerned about being less technical in that answer, in case of negative feed back, if it answered your question give it a tick. – X Tian Feb 28 '14 at 14:25
  • Some early startup script/service may require write access to /var, which is usually fine, unless it happens to be even before /var is properly mounted rw (which used to be done in the /etc/init.d/mountall.sh script for debian-based systems, nowadays it should be in a systemd service file), in which case you will have to tamper with your init ramdisk (or create one), really messy. – Franki Nov 26 '14 at 10:10
  • Also note that we used to have /var/run and /var/lock as mountpoints, which were required for proper persistent program state and lock files. However, they moved toward /run a while ago. – Franki Nov 26 '14 at 10:13
  • Further note that programs/services that actually do require very early persistent write access before static file systems (or even before the root file system is mounted/announced as mounted) are mounted are allowed to write to special places only, for debian it used to be /lib/init/rw, with a few further exceptions below /etc. – Franki Nov 26 '14 at 10:23
0

What folders inside /var are problematic? I've moved mysql datafolders, www, tomcat and other folders using symlinks to other partitions. Make sure you do this properly, keeping all rights exactly like they are:

sudo cp -rp /var/mysql /newpartition.

If mysql folder rights are changed, you will get into trouble and data might get lost. If you're not sure, copy the mysql folder, then rename it to a /var/mysql-backup, then symlink /var/mysql to the new partition, and see if it works. After a while you can remove the backup.

I'm focussing on mysql now. For Apache this is less problematic but still can cause problems. Test and see. Maybe this clears up enough space without having to move /var and get into trouble with log files like XTian says. For big logs, use log_rotate (with compression), and/or move them over to other partitions via the config of the application.

SPRBRN
  • 1,117