Increase meta-dnode redundancy in "some" mode #17339
Conversation
Loss of one indirect block of the meta dnode likely means loss of the whole dataset. It is worse than one file that the man page promises, and in my opinion is not much better than "none" mode. This change restores redundancy of the meta-dnode indirect blocks, while same time still corrects expectations in the man page. Signed-off-by: Alexander Motin <mav@FreeBSD.org> Sponsored by: iXsystems, Inc.
|
@akashb-22 ^^^ |
behlendorf
left a comment
behlendorf
left a comment
There was a problem hiding this comment.
Makes sense. I'd be surprised if this ended up significantly reducing the performance gain based on the usage stats I posted in this #13680 (comment). DMU_OT_DNODE was the smallest of the three big consumers.
robn
left a comment
robn
left a comment
There was a problem hiding this comment.
Yep, good one. I've run into metadnode indirect loss during recovery work, and it's extremely unfun. Every bit of extra detail helps!
amotin
added
Status: Accepted
Loss of one indirect block of the meta dnode likely means loss of the whole dataset. It is worse than one file that the man page promises, and in my opinion is not much better than "none" mode. This change restores redundancy of the meta-dnode indirect blocks, while same time still corrects expectations in the man page. Reviewed-by: Akash B <akash-b@hpe.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Rob Norris <robn@despairlabs.com> Signed-off-by: Alexander Motin <mav@FreeBSD.org> Sponsored by: iXsystems, Inc. Closes openzfs#17339
Loss of one indirect block of the meta dnode likely means loss of the whole dataset. It is worse than one file that the man page promises, and in my opinion is not much better than "none" mode. This change restores redundancy of the meta-dnode indirect blocks, while same time still corrects expectations in the man page. Reviewed-by: Akash B <akash-b@hpe.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Rob Norris <robn@despairlabs.com> Signed-off-by: Alexander Motin <mav@FreeBSD.org> Sponsored by: iXsystems, Inc. Closes openzfs#17339
Loss of one indirect block of the meta dnode likely means loss of the whole dataset. It is worse than one file that the man page promises, and in my opinion is not much better than "none" mode. This change restores redundancy of the meta-dnode indirect blocks, while same time still corrects expectations in the man page. Reviewed-by: Akash B <akash-b@hpe.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Rob Norris <robn@despairlabs.com> Signed-off-by: Alexander Motin <mav@FreeBSD.org> Sponsored by: iXsystems, Inc. Closes openzfs#17339
|
If entire dataset loss is possible, as mentioned in the opening comment, shouldn't the man page entry for this say that? Whatever the worst case is, the existing style/language of mentioning worst-case damage is ideal and should be preserved, I think. Under-stating at all is really something to avoid, on the topic of data loss. Even better would be to mention worst case and best case for all of them. So, if this, for example, always WILL lose one or more entire files (best case), and MAY lose an entire dataset (worst case), it'd be great to mention both of those bounds to assist users in designing for their requirements and failure tolerances. |
5 participants
Loss of one indirect block of the meta dnode likely means loss of the whole dataset. It is worse than one file that the man page promises, and in my opinion is not much better than "none" mode.
This change restores redundancy of the meta-dnode indirect blocks, while same time still corrects expectations in the man page.
Types of changes
Checklist:
Signed-off-by.