0

This is my disk state before attaching new virtual disk:

Filesystem            Size  Used Avail Use% Mounted on
/dev/xvde1            4.9G  4.6G  1.3M 100% /
tmpfs                 828M     0  828M   0% /dev/shm

When I attached new disk, I've created new partition and logical volume and mounted to the /var partition and this is the current state:

Filesystem            Size  Used Avail Use% Mounted on
/dev/xvde1            4.9G  4.6G  1.3M 100% /
tmpfs                 828M     0  828M   0% /dev/shm
/dev/mapper/vg_var-lv_var
                       49G  442M   46G   1% /var

Why the root partition is same and not reduced, 100% usage again?

4

You have not transferred the files that are in the original /var to the new /var so they are still occupying space on /dev/xvde1.

Adding a new /var is a non trivial task. Many of the files that take up the most space on in /var are log files that are opened by long running daemons. These files are often held open until the daemon is told to close them or the daemon is restarted.

To do this correctly you will need to

  • drop to single user mode.
  • mount the new /var somewhere in the filesystem.
  • copy the files from /var to the new var
  • rename the old /var to something else.
  • modify the fstab to mount the new /var on /var
  • delete the old /var
  • go back to muliti-user mode
| improve this answer | |
  • Is there some way to add a new /var without having to copy files? – Vasili Syrakis Apr 29 '14 at 9:54
  • @VasiliSyrakis I don't know the configuration of your system but you will need to copy at least some of the files in /var. Most likely you will get away with not copying the files in /var/log (you may need to recreate the directory tree there though). You will also likely find that you filled / because a log file got too big so you should look at configuring logrotate appropriately. – user9517 Apr 29 '14 at 10:03
2

Because you didn't remove the files from /dev/xvde1 first.

To free up the space (and create the appropriate directory structure on the filesystem) the simplest solution is to switch to runlevel 1, mount the filesystem elsewhere, migrate the files, then remount and switch back to your default runlevel....

# telinit 1
...
# umount /var
# mkdir /newvar
# mount /dev/mapper/vg_var-lv_var /newvar
# mv /var/* /newvar/
# umount /newvar
# mount /dev/mapper/vg_var-lv_var /var
# rmdir /newvar
# telinit 5

(needs to be run from the console)

| improve this answer | |
  • I am not sure if I can enter to runlevel 1 on aws ec2 machine... – ibedelovski Apr 29 '14 at 8:51
  • You might be able to loopback mount / and copy var that way. You'll still need to reboot after you've done it though, and running stuff might lose updates between copying and reboot. – Sobrique Apr 29 '14 at 10:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.