Re: What is difference between zfs and ufs?

On 8/17/26 12:37, Wojciech Puchar wrote:
>>> The only case that you may lose lot of data is that your disk fail 
>>> completely and is not mirrored or in other RAID protection.
>>
>>
>> Unless something has changed fairly recently, to my knowledge UFS does 
>> not have any explicit mechanism for combating silent data corruption.  
>> This is different to ZFS, which, unless you disable it, explicitly does.
> SATA/SAS interface have checksums. Disk drives store data with error 
> correcting codes.

   SATA/SAS are not the only interfaces. Despite checksums being present 
in drives, drives can fail in ways where the data gets stored+retrieved 
without flagging any issue. Quite rare but I used to have a drive that 
would do that. I had moved on from it but kept it as extra storage space 
and initially found it was causing issues when I used it for temporary 
storage during video rendering and kept observing corruption on final 
file review.

> Why add useless feature that just generates CPU load and memory traffic.

   The load that ZFS puts for its checksums is less than other 
implementations I've seen. Sun Microsystems worked with a drive 
manufacturer to be able to turn off the drive's checksum storage since 
ZFS was giving that protection + recovery of failure + a process that 
would be easy to sweep the data (and only the data) to look for errors 
when used with disks and even better with arrays. Sun got back a good 
amount of disk space when the drives didn't do the recovery and handling 
bad data was significantly faster than the disk's onboard retries 
cycling when issues were found. All at the cost of very minor load on 
the PC.

> I have never heard about "silent data corruption" you described to be 
> real problem anywhere. hardware does protect from it very well.

   Separate from my previously mentioned disk where failure was easy to 
find in bigger files, I had similar issues on a different drive when it 
was too poorly cooled but that was found as occasional sectors on disk 
becoming corrupted. Disk's hardware protection couldn't save the data 
after but a rewrite of the sector was fine. Heating the disk again would 
not re-damage that sector automatically; corruption was random.
   With SD memory cards used in devices and other memory choices that 
have been flaky in my experience, its nicer when a filesystem can say, 
"nope, that file is bad".
   So that is 3 failures just as my own personal non-business use but 
I'm the kind of person who has the luck of being able to buy a rock and 
its broken.
   I recently transferred data from FreeBSD to an NTFS disk to read into 
a Windows machine. By the time data would reach the other side it was 
intermittently being corrupted but the disk had no idea. I worked around 
that by bringing files containing checksums and any failed files I had 
to 'try again'. That is likely an issue with FreeBSD + ntfs-3g but its 
corruption nonetheless; if it went into a ZFS filesystem incorrectly 
then ZFS would gladly pass the corrupted results with a checksum pass 
too but if it was corruption after checksum calculations then it would fail.

> This ZFS feature like many others is nothing more than marketing.
> By the way i've personally seen ZFS total failures with completely 
> intact disks

   I've seen ZFS completely fail too. But then again I've seen UFS also 
completely fail despite how bulletproof you claim it is. Anyone not 
keeping a backup of their data and checking their integrity of the 
contents in the backup knows the data is not valuable or made a mistake.
   This isn't accounting for where people have had issues with both 
filesystems like UFS caused issues with the FreeBSD ports tree's 
contents because the ports count had gone too high (was that ever fixed 
or did all impacted users switch to ZFS?) or ZFS causes some issues due 
to lack of features/bugs which I think was with NFS and/or Samba.
   I wanted to make a copy of about 40GB of data because I didn't want 
to move it from where it was since part of it is a work in progress but 
needed it in another location to easily resolve some access permissions 
for what I was doing at the moment. Copying less data would have worked 
fine but I didn't want to sort out what would be needed vs not and just 
wanted to get on with using it quicker+easier and had enough space a 
copy could be comfortably made. A proper solution would be just point 
both projects at the same single source of data but I had reasons the 
two were divided. I did not expect the 40GB of data to copy from 
magnetic disk to magnetic disk when not in RAM already quickly but it 
took 1.68 seconds total; I'm still not used to block cloning being 
active but that was a nice unexpected convenience that made me do a 
double take that I hadn't messed up the copy.