All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: sandeen@sandeen.net, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/2] xfs_db: add an ls command
Date: Thu, 29 Oct 2020 10:20:56 +1100	[thread overview]
Message-ID: <20201028232056.GB7391@dread.disaster.area> (raw)
In-Reply-To: <20201028225046.GF1061252@magnolia>

On Wed, Oct 28, 2020 at 03:50:46PM -0700, Darrick J. Wong wrote:
> On Wed, Oct 28, 2020 at 12:27:03PM +1100, Dave Chinner wrote:
> > On Mon, Oct 26, 2020 at 04:32:41PM -0700, Darrick J. Wong wrote:
> > > +	hash = libxfs_dir2_hashname(mp, &xname);
> > > +
> > > +	dbprintf("%-18llu %-14s 0x%08llx %3d %s", ino, dstr, hash, xname.len,
> > > +			display_name);
> > > +	if (!good)
> > > +		dbprintf(_(" (corrupt)"));
> > > +	dbprintf("\n");
> > 
> > Can we get this to emit the directory offset of the entry as well?
> 
> Er... I think so.  Do you want to report the u32 value that gets loaded
> in ctx->pos?  Or the actual byte offset within the directory?

I'd suggest that it should be the same as the telldir cookie that is
returned by the kernel for the given entry.

> > > +	} else if (direct || !S_ISDIR(VFS_I(dp)->i_mode)) {
> > > +		/* List the directory entry associated with a single file. */
> > > +		char		inum[32];
> > > +
> > > +		if (!tag) {
> > > +			snprintf(inum, sizeof(inum), "<%llu>",
> > > +					(unsigned long long)iocur_top->ino);
> > > +			tag = inum;
> > > +		} else {
> > > +			char	*p = strrchr(tag, '/');
> > > +
> > > +			if (p)
> > > +				tag = p + 1;
> > > +		}
> > > +
> > > +		dir_emit(mp, tag, -1, iocur_top->ino,
> > > +				libxfs_mode_to_ftype(VFS_I(dp)->i_mode));
> > 
> > I'm not sure what this is supposed to do - we turn the current inode
> > if it's not a directory into a -directory entry- without actually
> > know it's name? And we can pass in an inode that isn't a directory
> > and do the same? This doesn't make a huge amount of sense to me - it
> > tries to display the inode number as a dirent?
> 
> I added this (somewhat confusing) ability so that fstests could resolve
> a path to an inode number without having to dig any farther into the
> disk format.
> 
> IOWs, you can do:
> 
> ino=$(_scratch_xfs_db -c 'ls -d /usr/bin/bash')
>
> to get the inode number directly.  Without this, you'd have to do
> something horrible like this...

You mean:

$ ls -i /bin/bash | cut -f 1 -d " "
175492
$

i.e. if you want to provide the inode number rather than just the
path, then let's use the same names as a real ls  implementation :)

> To map a path to an inode number.  I thought it made a lot more sense to
> do that in C (even if it makes the xfs_db CLI a little weird) than
> implement a bunch of string parsing after the fact.

I also suspect it would be simpler to separate it out into two
functions rather than the way it is implemented now....

> Maybe I should just simplify it to "display the inode number of whatever
> the path resolves to" instead of constructing an artificial directory
> entry.

*nod*

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2020-10-28 23:21 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-26 23:32 [PATCH 0/2] xfs_db: add minimal directory navigation Darrick J. Wong
2020-10-26 23:32 ` [PATCH 1/2] xfs_db: add a directory path lookup command Darrick J. Wong
2020-10-28  0:35   ` Dave Chinner
2020-10-29 18:38     ` Darrick J. Wong
2020-11-15 16:30   ` Eric Sandeen
2020-10-26 23:32 ` [PATCH 2/2] xfs_db: add an ls command Darrick J. Wong
2020-10-28  1:27   ` Dave Chinner
2020-10-28 22:50     ` Darrick J. Wong
2020-10-28 23:20       ` Dave Chinner [this message]
2020-10-29 18:41         ` Darrick J. Wong
2020-11-16 17:35 [PATCH v2 0/2] xfs_db: add minimal directory navigation Darrick J. Wong
2020-11-16 17:35 ` [PATCH 2/2] xfs_db: add an ls command Darrick J. Wong
2020-11-25 20:38 [PATCH v3 0/2] xfs_db: add minimal directory navigation Darrick J. Wong
2020-11-25 20:38 ` [PATCH 2/2] xfs_db: add an ls command Darrick J. Wong
2020-12-01 10:17   ` Christoph Hellwig
2021-01-09  6:27 [PATCHSET v3 0/2] xfs_db: add minimal directory navigation Darrick J. Wong
2021-01-09  6:27 ` [PATCH 2/2] xfs_db: add an ls command Darrick J. Wong
2021-01-16  1:24 [PATCHSET v3 0/2] xfs_db: add minimal directory navigation Darrick J. Wong
2021-01-16  1:24 ` [PATCH 2/2] xfs_db: add an ls command Darrick J. Wong
2021-01-20 15:24   ` Chandan Babu R
2021-02-03 19:42 [PATCHSET v4 0/2] xfs_db: add minimal directory navigation Darrick J. Wong
2021-02-03 19:43 ` [PATCH 2/2] xfs_db: add an ls command Darrick J. Wong
2021-02-09  4:09 [PATCHSET v5 0/2] xfs_db: add minimal directory navigation Darrick J. Wong
2021-02-09  4:10 ` [PATCH 2/2] xfs_db: add an ls command Darrick J. Wong

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=20201028232056.GB7391@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=darrick.wong@oracle.com \
    --cc=linux-xfs@vger.kernel.org \
    --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.