UFS UFS survive power failure

S

sagsaw

I have been using ext4 on linux and haven't face data corruption issues on powerfailure.

Also incase of a power failure, the fsck also quickly completes and fs recovers rather than the full check like ext2 or ext3 which was a time consuming process.

Does UFS also has similar behaviour?

I have installed 13.1 FreeBSD with disk formatted as UFS.

Is Soft updates plus journal enabled by default?
 
sagsaw said:
Also incase of a power failure, the fsck also quickly completes and fs recovers rather than the full check like ext2 or ext3 which was a time consuming process.
Click to expand...
ext4 uses journaling, ext2 and 3 don't.

sagsaw said:
Does UFS also has similar behaviour?
Click to expand...
Yes. Standard fsck(8) at boot runs in the background. So you don't even have to wait for it. But this does mean in some case it might fail because fsck(8) can't fix certain issues while it's only doing a backgrounded check. You can turn this on or off if you want.
Code: 
fsck_y_enable="NO"  # Set to YES to do fsck -y if the initial preen fails.
fsck_y_flags="-T ffs:-R -T ufs:-R"  # Additional flags for fsck -y
background_fsck="YES" # Attempt to run fsck in the background where possible.
background_fsck_delay="60" # Time to wait (seconds) before starting the fsck.
sagsaw said:
Is Soft updates plus journal enabled by default?
Click to expand...
It's been a while (switched to ZFS a long time ago) but I do believe those are all on by default. Can also be turned on or off after the filesystem has been created, see tunefs(8).
 
SirDice said:
ext4 uses journaling, ext2 and 3 don't.


Yes. Standard fsck(8) at boot runs in the background. So you don't even have to wait for it. But this does mean in some case it might fail because fsck(8) can't fix certain issues while it's only doing a backgrounded check. You can turn this on or off if you want.
Code: 
fsck_y_enable="NO"  # Set to YES to do fsck -y if the initial preen fails.
fsck_y_flags="-T ffs:-R -T ufs:-R"  # Additional flags for fsck -y
background_fsck="YES" # Attempt to run fsck in the background where possible.
background_fsck_delay="60" # Time to wait (seconds) before starting the fsck.

It's been a while (switched to ZFS a long time ago) but I do believe those are all on by default. Can also be turned on or off after the filesystem has been created, see tunefs(8).
Click to expand...
I am doing the unthinkable,
configuring AMD A9-9425 processor based 12gb ram 1 TB hdd LAPTOP as a server.

So ZFS would be hogging a lot of CPU as well as RAM hence UFS.

If UFS has SU+J, then at least on that its just like ext4 and I am ok with that as of now.
 
sagsaw said:
configuring AMD A9-9425 processor based 12gb ram 1 TB hdd LAPTOP as a server.
Click to expand...
Hardware doesn't define if the system is a server or not. It's how you use it that defines it. One of the first "servers" in my home lab was an old Siemens Pentium 90 desktop.
 
sagsaw said:
So ZFS would be hogging a lot of CPU as well as RAM ...
Click to expand...

A: Why do you say that? Do you have any evidence for that statement? Show your benchmarks!

B: If ZFS really uses more CPU (or RAM), perhaps that's for a reason? Maybe the reason is that you might be getting a benefit that might actually be valuable to you?

C: Given your particular system's balance between CPU power availability, and storage workload, do you think any extra usage by ZFS would be significant? Given that you have only a single (and small) disk, my hunch is that your storage or IO workload is minimal.
 
sagsaw said:
Does UFS also has similar behaviour?
Click to expand...
I use FreeBSD 17 years, I had a lot of power failures.
I had some issues with background_fsck on heavy loaded servers, it was like kernel panic on startup during background_fsck.
So I prefer to set background_fsck="NO" and fsck_y_enable="YES" on servers.
So in most cases UFS has no critical failures afrer unexpected power failures.
In some rare cases after powerfailures I had errors like kernel panic ufs_dirbad, but I had possibility to fix it in singleuser mode.
One of my FreeBSD servers this winter had 5-10 power failures per day during 3 months, and only once I have got a UFS error with kernelpanic which fsck can't fix automatically.
 
I use gjournal with UFS, background_fsck="NO" and fsck_y_enable="YES". Been doing this for a couple of years. Probably a dozen crashes due to power failures or out of memory errors. So far no permanent data loss. Longest fsck took about 30 minutes for a 5T partition holding about 1.2T of data.
 
I ran a hardware FreeBSD system on my lousy farm power (frequent power brown outs and failures) for years before I got a UPS. The hardware all got stretched, and eventually failed, but UFS with soft updates always recovered.

[I just replaced my 14 month old CyberPower pure sine wave UPS with an APC one, and could not be happier. The CyberPower is going to the tip!]
 
My opinions based solely on my experience and understanding. May not be 100% technically accurate, but should be pretty close semantically.

I'm with ralphbsz; the way ZFS is designed, ARC by default can take up a lot of free RAM. Please note I said "can" not "will". ARC is pretty much "read cache"; if the usage pattern is lots of reads of the same files, ARC may grow as designed, but you are getting a performance boost by not going to the physical device all the time. By design, ARC will give up memory as the system hits OOM conditions.

CPU? From what I've seen if ZFS is using lots of CPU it's because of write usage patterns. This has to do with transaction groups being the "unit of data" that gets written. If one is trying to write more data in a txg than the IO bandwidth to the physical device, yep ZFS starts to run a lot more, using more CPU.

I'm with everyone else regarding a UPS.
 
You must log in or register to reply here.
Back
Top