On Wed, 9 Nov 2011, Tomas Forsman wrote:
At all times, if there's a server crash, ZFS will come back along at next
boot or mount, and the filesystem will be in a consistent state, that was
indeed a valid state which the filesystem actually passed through at some
moment in time. So as long as all the applications you're running can
accept the possibility of "going back in time" as much as 30 sec, following
an ungraceful ZFS crash, then it's safe to disable ZIL (set sync=disabled).
Client writes block 0, server says OK and writes it to disk.
Client writes block 1, server says OK and crashes before it's on disk.
Client writes block 2.. waaiits.. waiits.. server comes up and, server
says OK and writes it to disk.
Now, from the view of the clients, block 0-2 are all OK'd by the server
and no visible errors.
On the server, block 1 never arrived on disk and you've got silent
corruption.
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.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
