> From: Andrew Gabriel [mailto:andrew.gabr...@cucumber.demon.co.uk]
> 
> > Temporarily set sync=disabled
> > Or, depending on your application, leave it that way permanently.  I know,
> for the work I do, most systems I support at most locations have
> sync=disabled.  It all depends on the workload.
> 
> Noting of course that this means that in the case of an unexpected system
> outage or loss of connectivity to the disks, synchronous writes since the last
> txg commit will be lost, even though the applications will believe they are
> secured to disk. (ZFS filesystem won't be corrupted, but it will look like 
> it's
> been wound back by up to 30 seconds when you reboot.)
> 
> This is fine for some workloads, such as those where you would start again
> with fresh data 

It's fine for any load where you don't have clients keeping track of your state.

Examples where it's not fine:  You're processing credit card transactions.  You 
just finished processing a transaction, system crashes, and you forget about 
it.  Not fine, because systems external to yourself are aware of state that is 
in the future of your state, and you aren't aware of it.

You're a NFS server.  Some clients write some files, you say they're written, 
you crash, and forget about it.  Now you reboot, start serving NFS again, and 
the client still has a file handle for something it thinks exists ... but 
according to you in your new state, it doesn't exist.

You're a database server, and your clients are external to yourself.  They do 
transactions against you, you say they're complete, and you forget about it.

But it's ok:  

You're a NFS server, and you're configured to NOT restart NFS automatically 
upon reboot.  In the event of an ungraceful crash, admin intervention is 
required, and the admin is aware, he needs to reboot the NFS clients before 
starting the NFS services again.

You're a database server, and your clients are all inside yourself, either as 
VM's, or services of various kinds....

You're a VM server, and all of your VM's are desktop clients, like a windows 7 
machine for example.  None of your guests are servers in and of themselves 
maintaining state with external entities (such as processing credit card 
transactions, serving a database, or file server.)  By mere virtue of the fact 
that you crash ungracefully implies your guests also crash ungracefully.  You 
all reboot, rewind a few seconds, no problem.

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
  • Re: [zfs-discuss]... Schweiss, Chip
    • Re: [zfs-dis... Edward Ned Harvey (opensolarisisdeadlongliveopensolaris)
    • Re: [zfs-dis... Neil Perrin
      • Re: [zfs... Richard Elling
        • Re: ... Schweiss, Chip
          • ... Edward Ned Harvey (opensolarisisdeadlongliveopensolaris)
          • ... Richard Elling
      • Re: [zfs... Edward Ned Harvey (opensolarisisdeadlongliveopensolaris)
        • Re: ... Neil Perrin
          • ... Edward Ned Harvey (opensolarisisdeadlongliveopensolaris)
  • Re: [zfs-discuss]... Edward Ned Harvey (opensolarisisdeadlongliveopensolaris)

Reply via email to