ZFS FreeBSD ZFS-on-root shrink partition

lockna

lockna

Hello!

I've had a little mishap :oops:
So far nothing bad happened.

The initial situation:

I have the following hard drives installed in my PC.
2 TB NVMe (EFI boot partition and the rest Windows)
1 TB NVMe (NTFS formatted, data grave)
2 TB SATA SSD (FreeBSD-ZFS and FreeBSD-Swap)
1 TB SATA SSD (NTFS, games)
500GB SSD (Linux and Windows Games)

Windows, FreeBSD and Linux all share the EFI boot partition.
Works great so far.
I previously had the partition for zfs on 128GB on the 2 TB SATA where I have FreeBSD on it.
Since it was getting tight (I still had free space, but 70% full) I thought I'd increase it to 256 or 512.
Unfortunately, I forgot the -s option in the gpart resize command and, as you can imagine, FreeBSD grabbed the whole 2TB (except for the few gb from swap).

Now I would like to reduce the size again, but that doesn't work quite so easily with ZFS.
I've read up on it, but wanted to check again whether these steps are the right ones I've taken.

My procedure would look like this:
`zfs snap zroot/ROOT@today` take a snapshot of the pool/dataset

I would then write the snapshot to a file and compress it with gzip
`zfs send -R zroot/ROOT@today > gzip /tmp/backup.gz`

Then destroy the zpool, resize the partition and create a new zpool. Then restore the snapshot of the file
`zcat /tmp/backup.gz | zfs recv -F zroot/ROOT@backup`
and make a rollback to this snapshot

`zfs rollback zroot/ROOT@backup`

Would that work?

I would have to do the whole thing from a boot stick, right? Because in single-user mode it doesn't help me because I'm on the installation and if I destroy the zpool it's stupid if I'm on there. So I would have to go into the boot stick and mount a Linux partition on /mnt, where I can then store my snapshot file. When I have created the zpool again, simply mount it again and pull down the snapshot.
Should actually work, shouldn't it?
 
That looks like a workable solution. And yes, you will need to boot from something else, the system won't let you pull out the rug from underneath it.
 
`zfs send -R zroot/ROOT@today > gzip /tmp/backup.gz` should be
`zfs send -R zroot/ROOT@today | gzip > /tmp/backup.gz`

What is your /tmp? If it is a memory filesystem then it's risky, not to mention probably not big enough. If it is on the memory stick, same problem with size. Obviously you need a storage place outside the ZFS big enough for the compressed snapshot.
 
If your pool doesn't have autoexpand property set to on and you stopped right after messing with partition size, not issuing the zpool online -e command, you may be able just set partition size/boundaries to wanted values and don't tell anybody about it :) But I would definitely make image of whole disk before trying.
 
cracauer@ said:
`zfs send -R zroot/ROOT@today > gzip /tmp/backup.gz` should be
`zfs send -R zroot/ROOT@today | gzip > /tmp/backup.gz`

What is your /tmp? If it is a memory filesystem then it's risky, not to mention probably not big enough. If it is on the memory stick, same problem with size. Obviously you need a storage place outside the ZFS big enough for the compressed snapshot.
Click to expand...
I don't know why I used /tmp. I would mount my linux partition under /mnt and do `gzip > /mnt/backup.gz`

Thanks for the command correction
 
ondra_knezour said:
If your pool doesn't have autoexpand property set to on and you stopped right after messing with partition size, not issuing the zpool online -e command, you may be able just set partition size/boundaries to wanted values and don't tell anybody about it :) But I would definitely make image of whole disk before trying.
Click to expand...
Unfortunately I have set the autoexpand property.😅
But thanks
 
You must log in or register to reply here.
Back
Top