On 8/10/06, Eric Schrock <[EMAIL PROTECTED]> 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,
- Eric
David,
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
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
