LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - General (http://www.linuxquestions.org/questions/linux-general-1/)
-   -   moving /home /root & /var to new partition (http://www.linuxquestions.org/questions/linux-general-1/moving-home-root-and-var-to-new-partition-385846/)

CrashedAgain 11-23-2005 11:39 AM

moving /home /root & /var to new partition
 
I have only 4.2G on my / partition (hda8) & am constantly running out of space, however I have a now empty 3.0G partition (hda5) so I want to move /home, /root and /var to hda5.

I have copied /home/crashedagain (the only user) to hda5 & mounted it via fstab as /home. (fstab entry: /dev/hda5 /home ext3 auto,users,exec 0 0). This seems to be OK & is now working.

Now I want to move /root and /var. These will now become /home/root and /home/var since the partition is mounted as /home.

Since the system expects to find /var not /home/var, can I just replace /var with a symlink to /home/var.

I have read that some applications will not follow symlinks.

Will there be problems with using a symlink here?

If so, what is the alternative?

abisko00 11-23-2005 11:47 AM

You need to create a separate partition for every out-sourced part of the root-tree. Although I have never tried your symlink solution, I can't imagine that this will work without trouble.

alienDog 11-23-2005 04:40 PM

How big is your var? Is there really a point in moving it at all? I think mount also has an option to move part of the filesystem to another place (--bind option?), see man mount for this.

CrashedAgain 11-23-2005 04:46 PM

It's not really that big (about 400M at the moment) but sometimes it needs a lot of space, for instance apt-get upgrade (Debian system) can download as much as 500 or 600M of .deb files. These can be cleaned up once the upgrade is done but it needs the space with it is doing the upgrade.

alienDog 11-23-2005 05:38 PM

400 MB seems a lot to me, mine is 17 MB :D I think you could make it happen with mount --bind so that you don't have to start partitioning hda5. Partitioning would seem a bin inconvenient.

CrashedAgain 11-23-2005 09:50 PM

crashedagain@desktop:~$ sudo du -s /var
391996 /var

most of it is in /var/lib & /var/log:
crashedagain@desktop:~$ sudo du -s /var/*
12 /var/autofs
3848 /var/backups
43412 /var/cache
162572 /var/lib
4 /var/local
12 /var/lock
172136 /var/log
48 /var/mail
4 /var/opt
252 /var/run
4328 /var/spool
5348 /var/tmp
16 /var/www
crashedagain@desktop:~$

most of /var/lib is apt & dpkg but there are a couple of really big files in /var/log:
crashedagain@desktop:~$ ls -ls /var/log | sort -n
{snip}
3436 -rw-r----- 1 root adm 3514197 Oct 20 06:33 syslog.2.gz
6556 -rw-r----- 1 root adm 6698794 Oct 20 06:33 messages.0
60720 -rw-r----- 1 root adm 62108905 Oct 20 04:54 debug.0
68892 -rw-r----- 1 root adm 70467752 Oct 20 06:25 kern.log.0

If I can get rid of these (and set the system up to keep them from growing...130Meg in log files is ridiculous!) then var will be small enough it won't be worth moving. I think logrotate is what cleans them up but I haven't figured out how it works yet.

alienDog 11-24-2005 09:49 AM

It has it's own configfile in /etc/ called logrotate.conf that defines how often the logs should be rotated and for how long the old logfiles should be kept. I have:

Code:

weekly
rotate 1
create
compress
/var/log/wtmp {
    monthly
    create 0664 root utmp
    rotate 1
}

It will rotate the logs weekly, keep 1 week worth of old logfiles, create new (empty) logfiles upon rotation and compress the old logs. In addition there might be some additional settings for certain logfiles in /etc/logrotate.d. They mainly deal with what happens when a certain logfile gets rotated (a bit like the part for wtmp above). Probably all you need to touch is /etc/logrotate.conf. Also make sure that logrotate gets run by cron (i.e. your machine is up at the time of the cronjob).

--edit--

Oh, and check the logging settings of your firewall, it can quite quickly bloat the logs, could be the reason for the size of your kern logfile. What goes into debug in your system?

CrashedAgain 11-24-2005 10:15 AM

That's pretty much what mine looks like too except I had rotate 5 so I had 5 .gz compressed old files for most logs instead of 1.
But the 60+ Meg files debug.0 and kern.log.0 were dated Oct 20 so why weren't they rotated? Does rotate work on ALL log files in /var/log or is it necessary to specify which ones get rotated? The manpage doesn't say.
I manually removed them & recreated empty files so as to avoid something looking for them & giving an error.
Drive space is probably OK now:
Filesystem Size Used Avail Use% Mounted on
/dev/hda8 4.2G 2.6G 1.4G 67% /
/dev/hda1 4.6G 3.0G 1.6G 66% /mnt/hda1
/dev/hda5 3.0G 791M 2.1G 28% /home
/dev/hda7 26G 8.9G 17G 36% /mnt/hda7
/dev/hdb1 25G 301M 23G 2% /mnt/hdb1
/dev/hdb2 50G 20G 28G 42% /mnt/hdb2

hda1 is windows, hda7 is vfat & hdb is a data drive. but with 1.6G free on hda8 I should be OK, Previously I had about 90% full on this drive.

btmiller 11-24-2005 11:44 AM

You probably shouldn't move /root to a new partition. The reason /root is put on the root filesystem is so that if there's a boot problem and Linux is unable to mount any other partitions besides the root partition, then root can still get to all his files. If /root is on a separate partition, he'll still be able to log in in that case, but won't have any access to files in his home dir.


All times are GMT -5. The time now is 12:13 AM.