> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Bob Friesenhahn
> The silent corruption (of zfs) does not occur due to simple reason
> that flushing all of the block writes are acknowledged by the disks
> and then a new transaction occurs to start the next transaction group.
> The previous transaction is not closed until the next transaction has
> been successfully started by writing the previous TXG group record to
> disk.  Given properly working hardware, the worst case scenario is
> losing the whole transaction group and no "corruption" occurs.
> Loss of data as seen by the client can definitely occur.

Tomas is right on this point - If you have a ZFS NFS server running with
sync disabled, and the ZFS server reboots ungracefully and starts serving
NFS again without the NFS clients dismounting/remounting, then ZFS hasn't
been "corrupted" but NFS has.  Exactly the way Tomas said.  The server has
lost its mind and gone back into the past, but the clients remember their
state (which is/was in the future) and after the server comes up again in
the past, the clients will simply assume the server hasn't lost its mind and
continue as if nothing went wrong, which is precisely the wrong thing to do.

This is why, somewhere higher up in this thread, I said, if you have a NFS
server running with sync disabled, you need to ensure NFS services don't
automatically start at boot time.  If your server crashes ungracefully, you
need to crash your clients too (NFS dismount/remount).

Personally, this is how I operate the systems I support.  Because running
with sync disabled is so DARN fast, and a server crash is so DARN rare, I
feel the extra productivity for 500 days in a row outweigh the productivity
loss that occurs on that one fateful day, when I have to reboot or
dismount/remount all kinds of crap around the office.

zfs-discuss mailing list

Reply via email to