3

I moved the /var directory to a new disk/partition, this part worked well, but I forgot to delete/move the old /var path and it is still using space on / (root) partition. How could I delete the old /var without redo all the process? Any ideas?

This is what I did so far:

fdisk -l
mount /dev/sdb /mnt/newvar/
df -h /mnt/newvar/
rsync -aqxP /var/* /mnt/newvar/
umount /mnt/newvar/  /mnt/var/
umount /mnt/newvar/
umount /disk2/
umount /mnt/newvar/
ls -la /mnt/newvar/
df -h
vim /etc/fstab

fstab content:

UUID=c7c73822-b6e8-4aa4-a4b2-41a70c29568f /boot ext2 defaults 0 2
/dev/mapper/zabbix--vg-swap_1 none swap sw 0 0
/dev/fd0 /media/floppy0 auto rw,user,noauto,exec,utf8 0       0
UUID="3195ad53-3aaa-418c-bdc0-d341e33d76d3" /var ext3 defaults 0 2

Result of the above command:

df -P / /var

Filesystem                  1024-blocks     Used Available Capacity Mounted on
/dev/mapper/zabbix--vg-root    11758232 10103908   1033988      91% /
/dev/sdb                       25671996  8720916  15640360      36% /var
AdminBee
  • 21,637
  • 21
  • 47
  • 71
Leonardo L. Southier
  • 49
  • 4
  • Welcome to StackExchange! Have you ever deleted a directory before? Please [edit your question](https://unix.stackexchange.com/posts/672128/edit) to show what you have tried that isn't working for you in this case. – Jim L. Oct 06 '21 at 15:32
  • Check the old /var isn't mounted, but the new one is. – Jeremy Boden Oct 06 '21 at 15:33
  • 1
    Can you show us the layout, a bit better? are you mounting the the partition at the `/var` mountpoint? – polemon Oct 06 '21 at 15:34
  • 1
    -1 for providing very little information, please [EDIT](https://unix.stackexchange.com/posts/672128/edit) and push more info in – Vlastimil Burián Oct 06 '21 at 17:16
  • 2
    Adding to the comment by @LinuxSecurityFreak, the output of `df -P / /var` would confirm that you have `/var` on a different partition. – doneal24 Oct 06 '21 at 17:59
  • 1
    @JimL., they have filesystem A, containing the root filesystem, and including `/var`. Then they make filesystem B, containing only the contents of `/var`, and mount that on `/var`. Now the contents of `/var` on filesystem A are not visible, since fs B is mounted on top of that. Deleting `/var` would remove the contents of B, probably causing some trouble, but would leave the now useless "invisible" stuff in place. So no, you can't look at that as just deleting a directory. – ilkkachu Oct 06 '21 at 18:13
  • 1
    The intent was to get the user to add more detail about the steps taken so far, and the actual point of trouble. With respect, @ilkkachu, your conjecture may be accurate, but it is conjecture none the less. – Jim L. Oct 06 '21 at 18:20
  • You actually have a `/dev/fd0` on your system? Haven't seen an automounted floppy drive in a while. – doneal24 Oct 06 '21 at 18:39
  • This is a sequencing confusion. During system startup, `/var` is created and used _before_ `/dev/sdb` is available. Moving `/var` doesn't seem like the best choice. Read `man hier` or https://www.man7.org/linux/man-pages/man7/hier.7.html – waltinator Oct 06 '21 at 21:28
  • @waltinator Having the operating system spread out over several disks has been around forever. All of the `/dev/sd?` devices become available to initrd at the same time. – doneal24 Oct 07 '21 at 12:28
  • If the answer below was useful, please consider accepting it so that it will show up in future searches. – doneal24 Oct 07 '21 at 14:47

1 Answers1

6

You can use a bind mount to access the original device. This does assume that the new /var is on a different partition.

mountpoint /var   # confirm that /var is mounted on a different partition. If not, STOP NOW
mkdir /mnt/root
mount --bind / /mnt/root
ls -lid /var /mnt/root/var    # these will be different inodes
ls /var /mnt/root/var   # different file contents if you've updated /var
rm -rf /mnt/root/var
mkdir /mnt/root/var
umount /mnt/root
rmdir /mnt/root

As usually suggested, back everything up before trying this Just as a suggestion to your new configuration. You did not do anything wrong but I would not have done it your way.

First suggestion: you should probably have made a partition in /dev/sdb and created your file system in /dev/sdb1. Maybe pedantic but I don't like using the disk volumes for file systems. Have had problems with this in the past.

Second: you could have created a PV volume on /dev/sdb1 and added that to /dev/mapper/zabbix to extend the volume. This would have put the entire LVM partition on two disks which will increase the probability of data loss if a disk dies but you would not have needed to move any data. However, if a disk dies in your setup you're probably hosed anyway so that is what backups are for.

doneal24
  • 4,910
  • 2
  • 16
  • 33