The documentation has a pretty ominous warning (
http://doc.freenas.org/9.3/freenas_storage.html#removing-a-log-or-cache-device):
"If the pool is running ZFSv15, and a non-mirrored log device fails, is replaced, or removed, the pool is unrecoverable and the pool must be recreated and the data restored from a backup. For other ZFS versions,
removing or replacing the log device will lose any data in the device which had not yet been written. This is typically the last few seconds of writes."
Yep.. totally correct. Just wrote a very long winded example (two actually) for why redundancy of the slog is important, even after ZFSv15.
Is this accurate? I can't comprehend a design where a clean unmount would cause data loss.
All modern file systems have write caches of some kind. In Windows (NTFS) it is cached in RAM. ext2/3/4 uses RAM too. ZFS allows you to use an SSD so you have a non-volatile storage for writes before they are written to the zpool. Since ZFS is hellbent on protecting your data at
any and all costs (and I literally mean any and all costs), this slog device is the solution to alternatively simply accepting that lost data is lost like
every other file system and volume manager design that ever existed has been doing for decades.
The difference is that ZFS:
- Allows you to ensure that no data is ever lost due to a loss of power. It even allows you to use multiple copies on different disks to ensure the data isn't lost. (yep.. there's that "any and all costs" and "hellbent on protecting your data")
- Won't let you mount a zpool in a condition where an slog device is missing without the -m flag being used so that you can restore the slog device if it is accidentally disconnected from the system.
Everything I just said is totally true. The reality is that you have been blind to all the missed writes your desktops and servers have potentially lost over your IT career. So maybe instead of asking why you can't comprehend a design where a clean unmount would cause data loss you should instead ask the
other file systems and volume managers to do what they are supposed to do and protect your darn data. :p
If you were around back in the Windows 95 and 98 days you'll remember how on an unclean shutdown a chkdsk was run on bootup automatically. Remember how it *always* found a problem and had to fix it (lost chains)? You do realize that every time it found a problem those lost chains were sectors that were marked as allocated and data may or may not have been written to those sectors, but then the allocation wasn't completed so the file system has no way of knowing what the data was for, if the data was even written, or what the actual condition of the chain is/was supposed to be? Every single time you clicked "fix" you were simply choosing to discard the lost data and continue the bootup.
Ouch!
Yep.... Mankind has been losing data for decades.
Welcome to the real world of not losing data anymore. ;)
