From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 00/13] xfs: metadata inode directories
Date: Thu, 17 Jan 2019 15:50:45 -0800 [thread overview]
Message-ID: <20190117235045.GM4424@magnolia> (raw)
In-Reply-To: <20190117233608.GL4424@magnolia>
On Thu, Jan 17, 2019 at 03:36:08PM -0800, Darrick J. Wong wrote:
> On Thu, Jan 17, 2019 at 06:26:36AM -0800, Christoph Hellwig wrote:
> > On Mon, Dec 31, 2018 at 06:22:26PM -0800, Darrick J. Wong wrote:
> > > Hi all,
> > >
> > > This series delivers a new feature -- metadata inode directories. This
> > > is a separate directory tree (rooted in the superblock) that contains
> > > only inodes that contain filesystem metadata. Different metadata
> > > objects can be looked up with regular paths.
> >
> > If we use path names we should just use regular VFS path lookup for
> > them.
>
> I'll research how to do that, since I'm not /that/ familiar with how to
> create dentries and do path lookups for a fs root that isn't really
> rooted anywhere.
Before I run off to another doc appt -- the strongest argument I can
think of for /not/ hooking into vfs path lookup is that if xfsprogs
needs to be able to look up metadata inodes then I'd have to port that
part of the vfs to userspace, and yuck.
xfs_db kind of needs it for the fsmap command, and xfs_repair needs to
be able to rebuild the realtime rmap btree inode.
--D
> > But why do we even need names? Can't we just work based on inode
> > numbers?
>
> How would that work, particularly if we start to create larger metadata
> directory trees? I might just be misreading your question, though.
>
> The reason to take this series (metadir) is so that we can do things
> like supporting multiple rt devices:
>
> %meta%/realtime/$device.bitmap
> $device.summary
> $device.rmap
> $device.refcount
>
> For some arbitrary number of realtime devices. We don't need it to
> support the XFS we have right now.
>
> --D
prev parent reply other threads:[~2019-01-17 23:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-01 2:22 [PATCH 00/13] xfs: metadata inode directories Darrick J. Wong
2019-01-01 2:22 ` [PATCH 01/13] xfs: create imeta abstractions to get and set metadata inodes Darrick J. Wong
2019-01-01 2:22 ` [PATCH 02/13] xfs: create transaction reservations for metadata inode operations Darrick J. Wong
2019-01-01 2:22 ` [PATCH 03/13] xfs: refactor the v4 group/project inode pointer switch Darrick J. Wong
2019-01-01 2:22 ` [PATCH 04/13] xfs: convert all users to xfs_imeta_log Darrick J. Wong
2019-01-01 2:22 ` [PATCH 05/13] xfs: iget for metadata inodes Darrick J. Wong
2019-01-01 2:23 ` [PATCH 06/13] xfs: define the on-disk format for the metadir feature Darrick J. Wong
2019-01-01 2:23 ` [PATCH 07/13] xfs: load metadata inode directory at mount time Darrick J. Wong
2019-01-01 2:23 ` [PATCH 08/13] xfs: convert metadata inode lookup keys to use paths Darrick J. Wong
2019-01-01 2:23 ` [PATCH 09/13] xfs: enforce metadata inode flag Darrick J. Wong
2019-01-01 2:23 ` [PATCH 10/13] xfs: read and write metadata inode directory Darrick J. Wong
2019-01-01 2:23 ` [PATCH 11/13] xfs: ensure metadata directory paths exist before creating files Darrick J. Wong
2019-01-01 2:23 ` [PATCH 12/13] xfs: disable the agi rotor for metadata inodes Darrick J. Wong
2019-01-01 2:23 ` [PATCH 13/13] xfs: enable metadata inode directory feature Darrick J. Wong
2019-01-01 9:29 ` [PATCH 00/13] xfs: metadata inode directories Amir Goldstein
2019-01-17 14:26 ` Christoph Hellwig
2019-01-17 23:36 ` Darrick J. Wong
2019-01-17 23:50 ` Darrick J. Wong [this message]
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=20190117235045.GM4424@magnolia \
--to=darrick.wong@oracle.com \
--cc=hch@infradead.org \
--cc=linux-xfs@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox