All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
	Eric Sandeen <sandeen@redhat.com>,
	linux-xfs <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH] xfs_db: properly set inode type
Date: Tue, 18 Jul 2017 12:20:14 +1000	[thread overview]
Message-ID: <20170718022014.GM17762@dastard> (raw)
In-Reply-To: <67d06f4f-73fc-577c-a12f-132821386597@sandeen.net>

On Mon, Jul 17, 2017 at 03:51:50PM -0500, Eric Sandeen wrote:
> 
> 
> On 06/28/2017 11:01 PM, Eric Sandeen wrote:
> >> I guess there's also the problem that if inodesize != 512 then what are
> >> we targeting, anyway?  If inodesize = 256 then we can only hit
> >> even-numbered inodes (not so bad) but if inodesize > 512 then do we jump
> >> back to wherever the inode starts?  Or just give the user what they
> >> asked for, even if it's garbage? 
> > Oh, hum. Right, big inodes.... 
> > 
> > So I'm trying to go from disk location to inode number, but the current
> > disk location may not even be the start of an inode.  Hell.  Well, I'm
> > sure I could craft a test to disallow "type inode" if the current location
> > cannot be on an inode boundary.  But is that too clever?  Should the
> > debug tool just do what the user asks?
> > 
> >> (FWIW I was fine with xfs_db being dumb and giving you exactly what you
> >> point it at, even if that makes no sense. :P)
> > yeah, if you do "daddr 0" "type agf" it'll squawk, too, so it's fine to
> > do the dumb user's bidding...
> 
> So as I have it today, issuing "type inode" will actually re-align you
> to an inode offset even if you're not on one:
> 
> xfs_db> sb 0
> xfs_db> addr rootino
> xfs_db> daddr
> current daddr is 128
> xfs_db> daddr 129
> xfs_db> type inode
> xfs_db> daddr
> current daddr is 128
> xfs_db> 
> 
> good? bad? indifferent? I'm thinking "bad" but we have no mechanism to
> read a batch of inodes in xfs_db other than by passing in a legit inode number.
> 
> And we have no mechanism to read only a /single/ inode...
> 
> Maybe print a warning about the re-alignment and carry on?

xfs_db is meant to be a developer tool, not idiot-proof. :P

i.e. some knowledge of the layout of the metadata you are trying
to examine is expected. I would not like xfs_db to change the daddr
I've specified simply because I tried to parse it as the wrong
object type....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  parent reply	other threads:[~2017-07-18  2:20 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-28  0:16 [PATCH] xfs_db: properly set inode type Eric Sandeen
2017-06-28  0:42 ` Darrick J. Wong
2017-06-28  0:47   ` Eric Sandeen
2017-06-28 22:45   ` Eric Sandeen
2017-06-28 23:54     ` Darrick J. Wong
2017-06-29  4:01       ` Eric Sandeen
2017-07-17 20:51         ` Eric Sandeen
2017-07-17 21:07           ` Darrick J. Wong
2017-07-18  2:20           ` Dave Chinner [this message]
2017-07-18  2:25             ` Eric Sandeen
2017-07-18  2:56               ` Dave Chinner
2017-07-18  1:51 ` [PATCH V2] " Eric Sandeen
2017-07-18 21:26   ` Bill O'Donnell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170718022014.GM17762@dastard \
    --to=david@fromorbit.com \
    --cc=darrick.wong@oracle.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --cc=sandeen@sandeen.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.