So far I understand that if a file is to be modified, it will first copy the data to be modified in a new location in the ZFS pool, then modify that new data and do all the ZFS voodoo it does, and ultimately do the very last step of the operation (which I think is the final change of the pointers). But what if the power goes out at exactly the same time as this very last step happens? Don''t I have a lost or corrupted file then? If not, can someone explain to me why? Thanks! This message posted from opensolaris.org
On Thu, Aug 10, 2006 at 12:11:46PM -0700, David Coronel wrote:> So far I understand that if a file is to be modified, it will first > copy the data to be modified in a new location in the ZFS pool, then > modify that new data and do all the ZFS voodoo it does, and ultimately > do the very last step of the operation (which I think is the final > change of the pointers). But what if the power goes out at exactly the > same time as this very last step happens? Don''t I have a lost or > corrupted file then? > > If not, can someone explain to me why?The uberblock update is atomic. There are basically two steps: 1. The uberblock is written in four locations on disk in a manner that allows us to find the ''correct'' uberblock even if we lose power (or overwrite) any of the copies. See the comments for vdev_config_sync() for all the gory details. 2. ZFS issues a ''synchronize cache'' command to the disk before proceeding with any further I/O, so that the state of the world is committed to disk before we start doing things like using free blocks, etc. Since we only need to update the uberblock with every transaction group, and we can leverage the on-disk write cache in the interim, this is not a huge performance overhead. Hope that helps, - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
On 8/10/06, Eric Schrock <eric.schrock at sun.com> wrote:> On Thu, Aug 10, 2006 at 12:11:46PM -0700, David Coronel wrote: > > So far I understand that if a file is to be modified, it will first > > copy the data to be modified in a new location in the ZFS pool, then > > modify that new data and do all the ZFS voodoo it does, and ultimately > > do the very last step of the operation (which I think is the final > > change of the pointers). But what if the power goes out at exactly the > > same time as this very last step happens? Don''t I have a lost or > > corrupted file then? > > > > If not, can someone explain to me why? > > The uberblock update is atomic. There are basically two steps: > > 1. The uberblock is written in four locations on disk in a manner that > allows us to find the ''correct'' uberblock even if we lose power (or > overwrite) any of the copies. See the comments for vdev_config_sync() > for all the gory details. > > 2. ZFS issues a ''synchronize cache'' command to the disk before > proceeding with any further I/O, so that the state of the world is > committed to disk before we start doing things like using free > blocks, etc. Since we only need to update the uberblock with > every transaction group, and we can leverage the on-disk write cache > in the interim, this is not a huge performance overhead. > > Hope that helps, > > - EricDavid, Plus, google for "a ring of 128 uberblocks", alright, I''ll do it for you :) http://www.opensolaris.org/jive/thread.jspa?messageID=46994#46915 Tao