Re: What is difference between zfs and ufs?

On 8/16/26 07:58, Johan Helsingius wrote:
> On 16/08/2026 4:42 pm, Edward Sanford Sutton, III wrote:
>>     Nope, 100% human
> Thanks for confirming that, and apologies for asking, but the
> rather dense formatting looked odd to me. Anyway, lots of
> useful information - thank you!

   Sometimes people like the help, sometimes they hate the wall of text. 
I have trouble doing 1 without the other. I totally get that now its a 
'did you just LLM me?' feeling reply. I have some talking//writing 
styles that sound 'very' LLM after only a little tweaking but I won't 
often do that.
   I'm not 100% against AI use but overall I trend toward the anti-AI 
camp in general. Thinking back, I have FUTO's offilne voice to text 
software on my Android phone which is mostly a hook and wrapper for the 
work of others and the heavy lifting comes from LLM.
   Dad (an engineer) taught me as a kid that, "just because you can do 
something, doesn't mean you should do it". People use LLMs in place of 
doing the work themself. By the design of LLMs, they are supposed to 
output something that 'seems correct' instead of something that 'is 
correct'. Some mistakes are more obvious but when you have to identify 
errors in a 'seems correct' produced output, its harder to observe the 
mistakes when its produced with a 'make it seem correct' goal. Sharing 
without checking means you leave it to others to see the errors in what 
you shared and offloading such work to others is usually annoying at best.
   Klara did an article where they tested LLMs with what they know well 
(ZFS). The outcome was that its output sounds good (at least I think 
that was in there) but was not good. Basically applying my previous 
paragraph makes it easy to expect that 'spoiler alert...' it failed to 
do good.

   Its getting a bit offtopic from 'ZFS vs UFS' but something else worth 
bringing up when someone is not sure which filesystem to use, they are 
not sure they have additional disk space and connection to quickly and 
easily backup+restore to try different things, but they don't have 'too 
much' data (needs to be < 1/2 the disk space), just partition your 
drive(s) into 2 equal size partitions per filesystem you want to 
experiment with.
   You can zfs send/recv, ufs dump/restore, cp or otherwise migrate a 
copy of data from the first to the second anytime you want to try/use 
something different and then you can switch from one partition being 
used to the second once ready. Root partitions can be complicated 
(=default) or simple (requires custom settings) to go between ZFS <-> UFS.
   ZFS and UFS do not have tools to defragment the data; a 
backup+restore is the normal process. You can minimize downtime by 
switching which partition you run from while you rewrite the other from 
its contents. To get a fully synchronized dataset you do need to take 
the system offline and do the transfer and both UFS and ZFS can do 
incremental transfers; do an initial big transfer while online, follow 
it with 1+ incremental transfers until it is fast enough that not much 
can change between it starting and you shutting down the system after. 
One last incremental transfer which should be small by design can be 
done without other software using the disk's files at the time gives you 
that extra integrity.
   Disadvantage to this is the second half of a magnetic drive is 
noticeably slower than the first; counterpoint is when using 1st 
partition you keep 'all' data in a much faster part of the disk. Another 
disadvantage is the extra I/O is concentrated on the drive instead of 
involving separate disks for half of it which often will bottleneck it 
by more that 1/2 the speed (unless external gets involved at an even 
slower speed) and for SSD and SMR devices you have twice the wear and 
cache flushes happening (minor but still there) plus SSDs will have less 
free pages for wear leveling when holding the data twice compared to once.
   These copies also are not a replacement for backups; a backup copy on 
a disk can still be ruined by the disk failing or corruption that hits 
the partition table or wanders outside one of the filesystems. Separate 
disks are needed to eliminate the other disadvantages. Just using a 
backup disk to write to and read from to refresh a partition means a 
temporary window where it is the data instead of being a backup and 
being a higher disk load means another reason why the backup may fail at 
that time...not fun when its your only copy.
   If you are doing an upgrade of disks in an array but have too few 
ports to add all the new disks beside all of the old ones, you can 
mirror some of the used partitions to unused partitions so that you are 
using fewer disks temporarily to get your used disk count down and free 
some more ports. Then you can add more new disks at once and can use up 
the double partitions on the new disks to minimize how many times the 
array goes through a full rebuild for some arrays. This may limit array 
redundancy. Mirrored arrays can do this to maintain redundancy but is an 
otherwise unneeded step if you can tolerate temporary redundancy loss as 
long as you put the mirrored copy onto a different disk than its 
original. RAID5 gets more messy but full resync can be where more 
savings come from if you cut down on resync cycles and by using mirrored 
copies its much less I/O then firing up every disk in a RAID5 to form a 
disk copy of 1 disk; gotta review the numbers to see which will be best 
for a given scenario.
   Anyways if you used it a while and you ran out of space and don't 
have the ability to add more or larger drives then you can always make 
sure you are using only the first of 2 partitions, resize the partition 
to include the extra space that was following it, and then expand the 
filesystem to use that additional space (forget if that is on or off by 
default for ZFS, think its an extra step for UFS). Shrinking is not an 
option for either filesystem still. ZFS has some minor 
performance/overhead consequences to how it expands a pool to double 
size vs creating it to be that larger size at the start but its usually 
minor enough to not care about.

>      Julf