Is Partitioning With ZFS as Easy as UFS?

Scribner

Scribner

I am about to do my second install of FreeBSD. My first install was over two years ago. For that install, I did the partitioning with "Auto (UFS) Guided Disk Setup" and I believe I chose GPT as the partition scheme type. I am a FreeBSD and computer science noob, and, therefore, I just went with the defaults for everything. My question is, can partitioning with ZFS be as easy as UFS in that I just need to accept the defaults for everything and proceed? It's my understanding ZFS is preferred on newer machines, which is why I want to go with ZFS this time around.
 
Thanks to the first two quick responders. Additional confirmation will not be seen as redundant.

A second, related question: Should I partition with ZFS rather than UFS this time? Is one better for beginners?
 
Scribner said:
Thanks to the first two quick responders. Additional confirmation will not be seen as redundant.

A second, related question: Should I partition with ZFS rather than UFS this time? Is one better for beginners?
Click to expand...

Both are easy to learn as a newbie if you open the corresponding manual.

Whether you want to use ZFS or UFS is up to you.
 
Not impossible to tell the installer to use ZFS instead of UFS in the partition you prepared. ZFS will behave, and not harass you with error messages. But, if you're using the whole disk, you can just skip the partitioning altogether, go with installer-provided defaults - and do a LOT of playing with ZFS after installation. With UFS, you kinda have to do some planning before you decide to partition the disk. With ZFS - you can do all your fine-tuning later.
 
Alexander88207 said:
Can you tell me examples?
Click to expand...
The planning basically revolves around partition boundaries on the disk. Root partition, swap, /usr, /etc, /tmp - If you use UFS, you gotta tell the installer how big you want those partitions to be, and in what order. Sometimes, the installer will complain that the swap is too small. And - once you tell the installer that this is how big you want the partitions, you're stuck, it's very difficult to properly resize them. Sure, not impossible to do some math, but you have to worry about the neighboring partitions. Generally, you can make partitions smaller, but not bigger. This is the headache that ZFS really saves me from.
 
Alexander88207 said:
Can you tell me examples?
Click to expand...
Suppose you want to put /home on a separate partition (which is good form), you would need to create a freebsd-ufs partition for it (disk has to have the required free space to be able to do that), newfs(8) it and add it to /etc/fstab. Then move some files around. You can't just create a separate filesystem without preparing the partitions. The size of those partitions are also set in advance, you could potentially expand an existing partition but you need to have free space after it or you will have to destroy other partitions to create that space. Shrinking partitions is quite dodgy to do in any case. So you will have to better plan ahead with respect to how you're going to split up a drive into its various partitions.

With ZFS you can just do zfs create -o mountpoint=/home zroot/home, and move the files. You don't need to worry about partitions or their sizes, you have the capacity of the whole pool at your disposal for every filesystem you create within that pool.
 
With UFS on GPT, you can just create two partitions, one for swap, and one freebsd-ufs with mountpoint = "/" for your root partition, and you'll be good to go. Easy-peasy.
 
Vull said:
With UFS on GPT, you can just create two partitions, one for swap, and one freebsd-ufs with mountpoint = "/" for your root partition, and you'll be good to go. Easy-peasy.
Click to expand...
Yeah, easy, but not a "Best Practice". Even with UFS, the installer provides different defaults. If you don't like them, you can do some pre-install planning/math, then enter the values. Or you can go with ZFS, and save yourself the headaches.
 
SirDice said:
You can't just create a separate filesystem without preparing the partitions. The size of those partitions are also set in advance, you could potentially expand an existing partition but you need to have free space after it or you will have to destroy other partitions to create that space. Shrinking partitions is quite dodgy to do in any case. So you will have to better plan ahead with respect to how you're going to split up a drive into its various partitions.
Click to expand...
Huge huge huge points right here. With filesystems like UFS, like ext2/3/4, they go on partitions of fixed size. If you guessed wrong (like made /var/log it's own partition and it's too small), too bad, you are reinstalling.
ZFS, you give it "the whole disk" (or a partition that is almost the whole disk) but each "partition" (dataset) lives in it. /var/log that can grow to the whole thing, but so can /home
 
Vull said:
With UFS on GPT, you can just create two partitions, one for swap, and one freebsd-ufs with mountpoint = "/" for your root partition, and you'll be good to go. Easy-peasy.
Click to expand...
Until a user wipes out the whole partition and the system can't boot because filesystem full and /var/log can't log.

But what you are saying is what all/almost all Linux systems do. Everything on one partition.
 
mer said:
Until a user wipes out the whole partition and the system can't boot because filesystem full and /var/log can't log.

But what you are saying is what all/almost all Linux systems do. Everything on one partition.
Click to expand...
I think that's what the FreeBSD installer does too, when it's on auto UFS, but it's been so long since I've used that option that I'm not exactly sure.

I'm not advocating either filesystem over the other, just saying it's another way of attaining the same, above-stated virtues: "You don't need to worry about partitions or their sizes, you have the capacity of the whole pool partition at your disposal for every filesystem directory path you create within that pool partition."

Are you saying that the user can't "wipe out" a zfs partition? Are you saying that you will never encounter "filesystem full" on a zfs partition? Seems like in either case you are ( a.) using a partition, and ( b.) limited only by the total size of the allocated space.
 
  • Like
Reactions: mer
Ok, with the caveats you've said, yes there is no/little difference in UFS with a single partition covering the whole device and ZFS covering the whole device.
Where the difference lies:
ZFS you can post create modify limits on a dataset. After the fact you can limit how much disk space /var/log can use.
UFS, you can't do that. So UFS single partition for everything you are stuck until repartitioning.
ZFS, "oh crap users are overrunning the /home dataset let me slap a limit there" to prevent it from going further. ZFS you could then add in new zpools/vdevs and migrate the datasets.
Yes you could do that with UFS, but you can again run into the partition/not partition question.
 
Vull said:
Are you saying that the user can't "wipe out" a zfs partition? Are you saying that you will never encounter "filesystem full" on a zfs partition? Seems like in either case you are ( a.) using a partition, and ( b.) limited only by the total size of the allocated space.
Click to expand...
With ZFS, you can have 'datasets' that protect folders from each other. You can limit the size of those 'datasets', set min/max size for every dataset, or you can let every dataset's max size to be as big as the disk itself. And you can do it any time, and adjust it later if you discover you made a mistake. You can guarantee a minimum size for the dataset that's mounted under zroot/home. ZFS basically frees you from the headaches associated with 'partitions'.
 
astyle said:
With ZFS, you can have 'datasets' that protect folders from each other. You can limit the size of those 'datasets', set min/max size for every dataset, or you can let every dataset's max size to be as big as the disk itself. And you can do it any time, and adjust it later if you discover you made a mistake. You can guarantee a minimum size for the dataset that's mounted under zroot/home. ZFS basically frees you from the headaches associated with 'partitions'.
Click to expand...
I know you're an advocate. I can see the possible advantage of setting a maximum size more readily than that of a minimum.
 
Vull said:
I know you're an advocate. I can see the possible advantage of setting a maximum size more readily than that of a minimum.
Click to expand...
Best I understand, setting a minimum size on a ZFS dataset guarantees you that /var/log won't overrun /home, even if /var/log fills up the rest of the disk with its max size being the size of the disk. That's how neat ZFS is. :p
 
mer said:
like ext2/3/4, they go on partitions of fixed size
Click to expand...
Not true, you could have e.g. LVM set where LVs can grow (and with some headache shrink) dynamically. Issue itself is with the device underlying the FS, not FS itself.

You could push quotas on UFS but that's a pain. However there are situations where single / is just enough.
In general my preference is to use ZFS where possible (if nothing else due to boot environments).

You could go with UFS too. The good old setup was (take that with bit of salt): something for /, magic size for swap, little bit for /tmp, small chunk for /var and the rest for the /usr. Problem is when you wanted to extend /var later. geom(8) to the rescue but be prepared for more headaches ahead.

You mentioned you are a beginner. Using FreeBSD installer difficulty of installing FreeBSD on ZFS is pretty much the same as on UFS, you just check for that option.
You can always check and test this first in the VM. VirtualBox is probably the most user friendly option under FreeBSD but you could try others too (bhyve, qemu).
 
_martin said:
Not true, you could have e.g. LVM set where LVs can grow (and with some headache shrink) dynamically. Issue itself is with the device underlying the FS, not FS itself.
Click to expand...
Is not the LVM (Logical Volume Manager) actually a layer on top of ext filesystem?
 
mer said:
Is not the LVM (Logical Volume Manager) actually a layer on top of ext filesystem?
Click to expand...
No. PV (physical volume, usually disk or its partition) is a building block of LVM. One of more PVs map to LV (logical volume) on which you create FS. By expanding the LV (and even PV if needed and device supports it) you can extend FS.
 
  • Like
Reactions: mer
You must log in or register to reply here.
Back
Top