From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 02/18] xfs: support storing records in the inode core root
Date: Thu, 30 Aug 2018 21:23:55 -0700 [thread overview]
Message-ID: <20180831042355.GB4359@magnolia> (raw)
In-Reply-To: <20180831022812.GJ5631@dastard>
On Fri, Aug 31, 2018 at 12:28:13PM +1000, Dave Chinner wrote:
> On Thu, Aug 30, 2018 at 11:31:48AM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <darrick.wong@oracle.com>
> >
> > Make it so that we can actually store btree records in the inode
> > core (i.e. enable bb_level == 0) so that the rtrmapbt can do this.
> >
> > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
>
> So this is so you don't need XFS_DINODE_FMT_RMAP_EXTENTS/BTREE
> inode fork types, right? i.e. there just XFS_DINODE_FMT_RMAP to
> indicate it's an rmap tree in the fork?
Yep.
> Could this code be used by the data fork, too? Sure, we need to
> keep the on-disk fork format info the same, but we could use this to
> kill the special BMDR formatting code it currently uses, right?
Hmm. FMT_EXTENTS uses di_nextents to count the number of records in the
data fork area, whereas FMT_BTREE stores the number of records in the
bmbt root in the data fork area, followed by bmbt keys/ptrs. I imagine
you could make the formats share code, but you'd have to special case
how much btree header gets written into the data fork area.
The maximum number of bmbt records that can fit in the data fork area
(factoring in alignment requirements) actually does depend on whether or
not we have to allocate space for the root block record count.
Might be worth deeper investigation...
(FWIW, FMT_RMAP always stores the number of root block records in the
data fork area, since it doesn't affect the max record count.)
--D
> (just trying to get an idea of whether we'll have to maintain two
> bits of code that do essentially the same thing forever)
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
next prev parent reply other threads:[~2018-08-31 8:29 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-30 18:31 [RFC PATCH v9.1 00/18] xfs: add realtime reverse-mapping support Darrick J. Wong
2018-08-30 18:31 ` [PATCH 01/18] xfs: make iroot_realloc a btree function Darrick J. Wong
2018-08-30 18:31 ` [PATCH 02/18] xfs: support storing records in the inode core root Darrick J. Wong
2018-08-31 2:28 ` Dave Chinner
2018-08-31 4:23 ` Darrick J. Wong [this message]
2018-08-30 18:31 ` [PATCH 03/18] xfs: widen xfs_rmap_irec fields to handle realtime rmapbt Darrick J. Wong
2018-08-30 18:32 ` [PATCH 04/18] xfs: introduce realtime rmap btree definitions Darrick J. Wong
2018-08-30 18:32 ` [PATCH 05/18] xfs: define the on-disk realtime rmap btree format Darrick J. Wong
2018-08-30 18:32 ` [PATCH 06/18] xfs: realtime rmap btree transaction reservations Darrick J. Wong
2018-08-30 18:32 ` [PATCH 07/18] xfs: add realtime rmap btree operations Darrick J. Wong
2018-08-30 18:32 ` [PATCH 08/18] xfs: prepare rmap functions to deal with rtrmapbt Darrick J. Wong
2018-08-30 18:32 ` [PATCH 09/18] xfs: add a realtime flag to the rmap update log redo items Darrick J. Wong
2018-08-30 18:32 ` [PATCH 10/18] xfs: add realtime rmap btree block detection to log recovery Darrick J. Wong
2018-08-30 18:32 ` [PATCH 11/18] xfs: add realtime reverse map inode to superblock Darrick J. Wong
2018-08-30 18:32 ` [PATCH 12/18] xfs: wire up a new inode fork type for the realtime rmap Darrick J. Wong
2018-08-30 18:33 ` [PATCH 13/18] xfs: wire up rmap map and unmap to the realtime rmapbt Darrick J. Wong
2018-08-30 18:33 ` [PATCH 14/18] xfs: enable realtime rmap btree Darrick J. Wong
2018-08-30 18:33 ` [PATCH 15/18] xfs: wire up getfsmap to the realtime reverse mapping btree Darrick J. Wong
2018-08-30 18:33 ` [PATCH 16/18] xfs: scrub the realtime rmapbt Darrick J. Wong
2018-09-02 8:13 ` Christoph Hellwig
2018-08-30 18:33 ` [PATCH 17/18] xfs: cross-reference realtime bitmap to realtime rmapbt scrubber Darrick J. Wong
2018-08-30 18:33 ` [PATCH 18/18] xfs: cross-reference the realtime rmapbt Darrick J. Wong
2018-09-02 8:14 ` [RFC PATCH v9.1 00/18] xfs: add realtime reverse-mapping support Christoph Hellwig
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=20180831042355.GB4359@magnolia \
--to=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--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;
as well as URLs for NNTP newsgroup(s).