Hi Darrick. > > >> This patch adds a '-x' option (another awkward thing is that > > >> the codebase doesn't support long options) to address > > >> problamatic images by searching for the real dir, the reason > > >> that I don't enable it by default is that I'm not very confident > > >> with the xfsrestore codebase and xfsdump bulkstat issue will > > >> also be fixed immediately as well, so this function might be > > >> optional and only useful for pre-exist corrupted dumps. > > > > > > As far as fixing xfsdump -- wasn't XFS_BULK_IREQ_SPECIAL_ROOT supposed > > > to solve that problem by enabling dump to discover it it's really been > > > passed the fs root directory? > > > > Yes, but as I understand it this patch is to allow the user to recover > > from an already corrupted dump, at restore time, right? > > Right, though I still haven't seen any patches to dump to employ > XFS_BULK_IREQ_SPECIAL_ROOT to avoid spitting out bad dumps in the first > place. I think the heuristic that we applied is probably good enough, > but we might as well query the kernel when possible. > > > This still feels like deep magic in xfsdump that most people struggle > > to understand, but it seems clear to me that the changes here are truly > > isolated to the new "-x" option - IOWs if "-x" is not specified, there is > > no behavior change at all. > > > > Since this is intended to attempt recovery from an already-corrupted > > dump image as a last resort, and given that there are already some xfstests > > in place to validate the behavior, I feel reasonably comfortable with > > merging this. > > Documentation nit: Can restore detect that it's been given a corrupt > dump, and if so, should it warn the user to rerun with -x? > > --D I am assuming that even though you have concerns about not having XFS_BULK_IREQ_SPECIAL_ROOT employed in dump yet (and the documentation nit :), you are not opposed to have this patch merged? -- Carlos Maiolino
