Is it possible to safely reduce the root partition

[elimelech007]

root@F3ja:/home/luba # gpart show
=>       40  117210160  ada0  GPT  (56G)
         40       1024     1  freebsd-boot  (512K)
       1064  115343360     2  freebsd-ufs  (55G)
  115344424    1865776     3  freebsd-swap  (911M

I would like to reduce the root partition and thereby increase the swap partition.

 

[SirDice]

No, not without destroying the existing partition (and the data it contains).

If you need more swap you may want to add a swapfile instead.
Handbook: 11.12.2. Creating a Swap File

 

[ralphbsz]

But the next time you install, you can make it much smaller. For example, on my 11.2 machine, the root partition uses 160M, plus /var uses 849M, and /usr is at 2.3G (but that could be cleaned up a lot, I just don't feel like wasting time on it). You can survive easily with a 5-10G root partition.

 

[dieselriot]

Not sure if this is a good place to ask, but why can't UFS filesystems be shrinked, like ext can?

 

[ShelLuser]

Not sure if this is a good place to ask, but why can't UFS filesystems be shrinked, like ext can?

This is a rough theory based on my experiences with UFS (as in: I never studied the source code) but as far as I know this has everything to do with the robustness of the filesystem. In specific: the superblock copies. These are made based on the size of the filesystem and they provide (some) extra data protection in the event when something goes wrong; if the bootsector gets whacked then this isn't necessarily the end of the filesystem. There's also the issue of the 8%: every UFS filesystem has a reserved space (can't be used by normal users) which is used by the system.

Growing the filesystem (see growfs(8)) doesn't have to affect any of this, at best a new copy of the superblock has to be created but that shouldn't be too big an issue. But shrinking the filesystem can result in a superblock copy becoming obsolete (so it has to be removed) and the reserved space would also have to be recalculated and that could cause some issues.

Theoretically you could consider removing and rebuilding the whole lot but that would automatically also affect the health of the filesystem (what if something went wrong afterwards?). As such it's safer (and maybe easier) not to provide this feature at all.