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. -r
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? -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20070917/0b87dc4f/attachment.bin>
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. -r > -- > Pawel Jakub Dawidek http://www.wheel.pl > pjd at FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
On Mon, Sep 17, 2007 at 05:22:04PM +0200, Pawel Jakub Dawidek wrote:> 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?I think Roch must have meant that ZFS will detect the data loss and recover as best it can. But the loss could be significant enough to render the filesystem useless to you, so I suppose that the distinction Roch draws here isn''t very helpful.
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