UFS How unite two slice in one

Hello ! The problem is this. I want upgrade version FreeBSD 12.3 not enough space in /var. Took a bite off /usr
gpart -i 4 -s 26G -a 4K ada0.
How add in /var free-space 4G ?
 

Attachments

  • gpart show.png
    gpart show.png
    46.1 KB · Views: 146
Normally you don't want /usr or /var on different filesystems. Booting can have problems.
You could try /var in fstab but no guarantees.
 
Hello ! The problem is this. I want upgrade version FreeBSD 12.3 not enough space in /var. Took a bite off /usr
gpart -i 4 -s 26G -a 4K ada0.
How add in /var free-space 4G ?

It would be useful to have posted your gpart show in text, e.g. in a 'code' block, plus either 'df' output or your /etc/fstab, to connect your partitions to filesystems - so I'll guess a bit.

There are two obvious ways to deal with this; either should be done in single-user mode to avoid any updates to /var.

Either way, first backup your existing /var, safest with dump(8) to e.g. /usr/vardump. The first method relies on this; for the second it's good insurance.

1) per handbook section 18.3: IFF the 4G new free space is adjacent to your present /var (the 2.9G?) then you could

a) rm -rf /var/*
b) grow present /var into the free space with gpart(8), then
c) restore(8) /var contents from the vardump.

2) the old tried and tested way of using symlink/s to add space to /var from elsewhere on the disk.

Make 4G free space a new partition with gpart, call it e.g. '/var2'.
# mkdir -p /var2
and add it to /etc/fstab if gpart did not.

With the subdir of /var that needs more space, e.g. /var/log:

Code:
# mv /var/log /var2
# ls /var2/log  # check ok
# ls /var/log    # check empty
# ln -s /var2/log /var/log
# ls /var/log    # check ok

Repeat if needed for other dirs, maybe /var/db ?

# reboot

If all's well you can remove the vardump, or back it up ...
 
Normally you don't want /usr or /var on different filesystems. Booting can have problems.

What problems, specifically?

Some people have been using separate filesystems for those and sometimes /tmp and/or /home for 20+ years.

Sure, it's best that you know what you're doing. It's easy to underestimate just how huge most software has grown in just a few years; I know I've done that with 12.3-RELEASE.
 
It would be useful to have posted your gpart show in text, e.g. in a 'code' block, plus either 'df' output or your /etc/fstab, to connect your partitions to filesystems - so I'll guess a bit.

There are two obvious ways to deal with this; either should be done in single-user mode to avoid any updates to /var.

Either way, first backup your existing /var, safest with dump(8) to e.g. /usr/vardump. The first method relies on this; for the second it's good insurance.

1) per handbook section 18.3: IFF the 4G new free space is adjacent to your present /var (the 2.9G?) then you could

a) rm -rf /var/*
b) grow present /var into the free space with gpart(8), then
c) restore(8) /var contents from the vardump.

2) the old tried and tested way of using symlink/s to add space to /var from elsewhere on the disk.

Make 4G free space a new partition with gpart, call it e.g. '/var2'.
# mkdir -p /var2
and add it to /etc/fstab if gpart did not.

With the subdir of /var that needs more space, e.g. /var/log:

Code:
# mv /var/log /var2
# ls /var2/log  # check ok
# ls /var/log    # check empty
# ln -s /var2/log /var/log
# ls /var/log    # check ok

Repeat if needed for other dirs, maybe /var/db ?

# reboot

If all's well you can remove the vardump, or back it up ...
Maybe you need to copy over /var to another place then remake the partition, remake the filesystem and copy /var back over to the new (bigger) location.
 
What problems, specifically?

Some people have been using separate filesystems for those and sometimes /tmp and/or /home for 20+ years.

Sure, it's best that you know what you're doing. It's easy to underestimate just how huge most software has grown in just a few years; I know I've done that with 12.3-RELEASE.
/home & /tmp can be on separate filesystems. /usr can't as far as i know.
Sometimes it can be advantage to put specific subdirectories of /var on separate filesystems
 
OP, not sure which partition is which, labels and fstab would be nice to help us.
I'm guessing here: You've taken space from the end of /usr and are trying to add it to the beginning of /var?

I know "growfs" can let you expand a UFS partition, I'm not sure if you can shrink one.
Adding space at the beginning? Almost a guarantee to get things messed up.

If you're already at the point of mucking with partition tables, you would be better off trying to pull any needed data off the system and then install fresh instead of trying to upgrade.

above is all my opinion, feel free to ignore.
 
Maybe you need to copy over /var to another place then remake the partition, remake the filesystem and copy /var back over to the new (bigger) location.

That's exactly what I detailed above, Alain. dump(8) is just the right tool for backups, especially of small partitions as shown by the OP. It keeps all links, hard and soft, file flags etc intact.

Growing the partition can be done with gpart, IFF the free space is adjacent to the existing /var. I suspect so, but OP needs to confirm.

Yes, once the /var partition is grown it will need newfs'ing before restoring from dump; I should have mentioned that.

If not adjacent, the 4G free space can just become a new partition, where method 2 above can be used to add 4G to the existing /var. Adding space to filesystems via symlinks to directories on other partitions is simple and uncontrovertial. I've been doing it since the late '90s.
 
/home & /tmp can be on separate filesystems. /usr can't as far as i know.

There is nothing special about /usr in that respect. There are still handbook references to suggested sizes for /, /var and /usr filesystems, though I doubt they'll survive much longer.

I find it rather sad that in the more recent modernisations of the handbook, which most new users tend to rely upon, much older knowledge and methods are not merely deprecated, but more or less obliterated.

Sometimes it can be advantage to put specific subdirectories of /var on separate filesystems

Yep. This thread seems to be just such a case <&^}=
 
Back
Top