On 10 November, 2011 - Will Murnane sent me these 1,5K bytes:

> 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.

Which is exactly what this thread is about, consequences from
-disabling- sync.

Tomas Forsman, st...@acc.umu.se, http://www.acc.umu.se/~stric/
|- Student at Computing Science, University of Umeå
`- Sysadmin at {cs,acc}.umu.se
zfs-discuss mailing list

Reply via email to