Re: [RFC PATCH] db: Stop core dumping on attr3 if block header is not recognized

[Carlos Maiolino <cmaiolino@redhat.com>]

On Mon, Apr 23, 2018 at 08:54:37AM -0600, Eric Sandeen wrote:
> 
> 
> On 4/23/18 2:26 AM, Carlos Maiolino wrote:
> >> So it seems like casting it into something the user might expect would
> >> be better?
> >>
> > Not sure, in this case, the 'user' is expaecting an attr3 type, while xfs_db is
> > reading some other random, non attr3 type block. So, I wonder, what you meant by
> > 'something the user might expect'? The way I view it is: "The user is expecting
> > attr3 type", but there is no attr3 data in the block being read, so, the way I
> > understand what you meant, was trying to print the current block using attr3
> > format, which, IMHO, might fool the xfs_db user. I think saying the block
> > doesn't match attr3 format, and printing a possible magic number found in the
> > block works better. After all, xfs_db is a developer tool, not an user tool. If
> > I use myself and my xfs_db usage as an example:
> > If I try to print some block as attr3, and I see a message saying no attr3
> > format has been found, and I got a dump of a possible magic number, I can check
> > if that magic number matches some metadata format, or if it doesn't look as a
> > magic at all, I can simply consider the block corrupted. But well, this is just
> > my way to view it.
> > 
> 
> So, don't get too hung up on your "it's not actually an attr3 block" testcase;
> imagine the scenario where it /is/ an attr3 block, but the magic is
> corrupted.  Now imagine that you want to examine the block (to see what the magic
> was, and what the other fields were, and if it even looks like an attr3 block,
> or something else), and possibly even fix a field manually.
> 
> If all you get is "unknown" that's not very helpful.  You /could/ hexdump it
> and count bytes, but that sucks.
> 
> If you tried the same thing on i.e. an agf header (with bitflipped magic) you
> would still be able to print the whole structure, and see what was wrong.
> 
> Because attr3 only prints semi-validated blocks today, and refuses to show you
> anything that doesn't match, it's a far more difficult situation.  The root
> cause is that "attr3" is a multiplexer that will really decide between 3 different
> formats, but will /only/ show you one of the 3 if the magic is undamaged.
> 
> That's why I was wondering about explicit types for the leaf/block etc so you
> can force xfs_db to show it to you in that format (like you could with i.e. agf).
> 

Got your concern, and I agree, I can work on it if you are not in a hurry to get
it merged.

> Meh, for now maybe I will just merge the "don't segfault" patch, it's at least an
> improvement.  A nicer outcome isn't our most pressing problem I guess.
>

That would be great, I can work on the leaf/block separation in the meantime
without having my xfs_db crashing on it :)

Cheers
> -Eric
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Carlos