Roch - PAE wrote: > Pawel Jakub Dawidek writes: > > On Mon, Sep 17, 2007 at 03:40:05PM +0200, Roch - PAE wrote: > > > > > > Tuning should not be done in general and Best practices > > > should be followed. > > > > > > So get very much acquainted with this first : > > > > > > http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide > > > > > > Then if you must, this could soothe or sting : > > > > > > http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide > > > > > > So drive carefully. > > > > "If some LUNs exposed to ZFS are not protected by NVRAM, then this > > tuning can lead to data loss or application level corruption. However > > the ZFS pool integrity itself is NOT compromised by this tuning." > > > > Are you sure? Once you turn off flushing cache, how can you tell that > > your disk didn't reorder writes and uberblock was updated before new > > blocks were written? Will ZFS go the the previous blocks when the newest > > uberblock points at corrupted data? > > > > Good point. I'll fix this. I don't know if we look for > alternate uberblock but even if we did, I guess the 'out of > sync' can occur lower down the tree.
I think that it would also be nice to add to section on limiting ARC size a note on how to view current limit and other ARC statistics with kstat Victor _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
