On Thu, Nov 10, 2011 at 14:12, Tomas Forsman <st...@acc.umu.se> wrote: > On 10 November, 2011 - Bob Friesenhahn sent me these 1,6K bytes: >> 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. > When a client writes something, and something else ends up on disk - I > call that corruption. Doesn't matter whose fault it is and technical > details, the wrong data was stored despite the client being careful when > writing. If the hardware is behaving itself (actually doing a cache flush when ZFS asks it to, for example) the server won't say OK for block 1 until it's actually on disk. This behavior is what makes NFS over ZFS slow without a slog: NFS does everything O_SYNC by default, so ZFS runs around syncing all the disks all the time. Therefore, you won't lose data in this circumstance.
Will _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
