Solved false assumption about live dd copy being similar to power failure state

[cy@]

I don't understand you cy, really I don't. I'm here for 15 years, I helped many people with many problems, debugged handful of interesting kernel bugs and wrote a patch or two for them.

We all have weak points, we all get tunel vision from time to time and start our research on a false assumption. I'm parroting it here like an idiot. Please have a look on my original post -- I always send snaphosts when I actually need to move data from one to the other. Or I dd something that is not being used at the moment.

This thread got me excited because I built all my tests on a false premise that dd copy state would be similar to a power failure state during heavy write. This assumption then got derailed as I was getting mixed results and thought maybe it's a bug.

While I can honestly say I'm not stupid ( well smart enough to know how much I don't know in life ) I like to share in community and talk around people when I feel excited about something. Of course that means sometimes being wrong.
I must say that this experience I had here now was not a pleasant one.

And last time: I never ever intended dd to do a backup of a live system.

No worries.

Just remember that when ZFS writes metadata, it creates a completely new tree from the inode up to a brand new uberblock. Then the pointer to the new uberblock is written. It is done this way because a disk device has only one actuatator and only one I/O operation can be done at a time. (SSDs do the same.) This makes the operation virtually atomic, providing ZFS rock solid RAS (reliability, availability, serviceability) over other filesystems.

UFS does no such thing so writes to UFS usually don't make a mess.

BTW, my clone of the 1 TB SSD to 1 TB hard disk worked. I needed to test something on the Windows partition. Of course what I tried on Windows messed everything up. Good thing I took a clone before testing or I'd have been sunk, losing the contents of the entire 1 TB. Yay Windows.