On May 19, 2010, at 2:29 PM, Don wrote: > "Since it ignores Cache Flush command and it doesn't have any persistant > buffer storage, disabling the write cache is the best you can do." > > This actually brings up another question I had: What is the risk, beyond a > few seconds of lost writes, if I lose power, there is no capacitor and the > cache is not disabled?
The data risk is a few moments of data loss. However, if the order of the uberblock updates is not preserved (which is why the caches are flushed) then recovery from a reboot may require manual intervention. The amount of manual intervention could be significant for builds prior to b128. > My ZFS system is shared storage for a large VMWare based QA farm. If I lose > power then a few seconds of writes are the least of my concerns. All of the > QA tests will need to be restarted and all of the file systems will need to > be checked. A few seconds of writes won't make any difference unless it has > the potential to affect the integrity of the pool itself. > > Considering the performance trade-off, I'd happily give up a few seconds > worth of writes for significantly improved IOPS. Space, dependability, performance: pick two :-) -- richard -- Richard Elling rich...@nexenta.com +1-760-896-4422 ZFS and NexentaStor training, Rotterdam, July 13-15, 2010 http://nexenta-rotterdam.eventbrite.com/ _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
