On Sat, 25 Jul 2009, roland wrote:
When that happens, ZFS believes the data is safely written, but a
power cut or >crash can cause severe problems with the pool.
didn`t i read a million times that zfs ensures an "always consistent
state" and is self healing, too?
so, if new blocks are always written at new positions - why can`t we
just roll back to a point in time (for example last snapshot) which
is known to be safe/consistent ?
As soon as you have more then one disk in the equation, then it is
vital that the disks commit their data when requested since otherwise
the data on disk will not be in a consistent state. If the disks
simply do whatever they want then some disks will have written the
data while other disks will still have it cached. This blows the
"consistent state on disk" even though zfs wrote the data in order and
did all the right things. Any uncommitted data in disk cache will be
forgotten if the system loses power.
There is an additional problem if when the disks finally get around to
writing the cached data that they write it in a different order than
requested while ignoring the commit request. It is common that the
disks write data in the most efficient order, but it absolutely must
commit all of the data when requested so that the checkpoint is valid.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
