pseudo stirrup
hello hello... have a customer that hit bug 1567167. workaround is a flag change: setflag wafl_repl_max_inos_grow_pct 0
kb states: "Set to 0 keeps maximum inode count same as total inode count. This would generate event notification when relationship is broken."
trying to better understand what this change does and potential for negative impact to node.
lapis wagon
Sorry for answering with a question but is your customer unable to upgrade? Upgrading to a fixed release would probably be the "best" solution and would avoid tinkering with setflags.
pseudo stirrup
they plan on upgrading to a version that is fixed in the next month or so. i was just wondering about the flag...
lapis wagon
wafl_repl_max_inos_grow_pct was introduced to address issues where a SnapMirror destination volume would complain about nearly running out of files/inodes but then there was no way to actually grow them on a destination volume (it's all automatic). wafl_repl_max_inos_grow_pct's default value causes total files to grow more quickly to avoid those nearly-full alerts and/or any anxiety about moving clients to a destination volume which doesn't have many free inodes/files. But due to this issue, it doesn't work properly.
So making this flag 0 will workaround the defect but the caveat is that the behavior goes back to what it was before. In other words, inodes may get near-full on snapmirror destination volumes again resulting in alerts. In addition if you perform a DR failover to the destination volume you may need to grow inodes manually.
However, inodes will still grow automatically on destination volumes. Also you might not be experiencing any isues with nearly running out of inodes on your snapmirror destinations, in which case you're unlikely to notice anything at all.