> 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 zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss