From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 03/16] xfs: rmap btree add more reserved blocks
Date: Fri, 11 Mar 2016 09:09:45 +1100 [thread overview]
Message-ID: <20160310220945.GY30721@dastard> (raw)
In-Reply-To: <20160310142207.GD29058@infradead.org>
On Thu, Mar 10, 2016 at 06:22:07AM -0800, Christoph Hellwig wrote:
> Sorry for the second reply to the same mail - I expect this defintion to
> be in patch 7, where it logically belongs..
>
> > +#define XFS_RMAP_BLOCK(mp) \
> > (xfs_sb_version_hasfinobt(&((mp)->m_sb)) ? \
> > XFS_FIBT_BLOCK(mp) + 1 : \
> > XFS_IBT_BLOCK(mp) + 1)
>
> Is there any good reason for the variable offset for the rmap block.
> Yes, it saves one otherwise unused block per AG, but fixed offsets
> for metadata make a format much easier to understand.
The root btree blocks are not a fixed location. The moment the tree
splits to the root we get a new root block and the old root is now
at a lower level of the tree. IOWs, it doesn't matter if there is a
hole at the time of growfs/mkfs laying out the initial tree roots
because they are going to move around anyway.
Also, it depends on the sector vs block size as to where these are
initially located, too. A disk with 512 byte sectors and 4k block
size results in the root btree blocks being located from fsb 2-7.
On a 4k sector/4k block size fs has the root btree blocks located
from fsb 4-9.
Hence I really don't think it matters if the initial location
changes depenedent on features and geometry as you have to look it
up with xfs_db anyway to find it even on a pristine new
filesystem...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2016-03-10 22:09 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-08 4:16 [PATCH 0/16] xfs: first part of rmapbt functionality Dave Chinner
2016-03-08 4:16 ` [PATCH 01/16] xfs: introduce rmap btree definitions Dave Chinner
2016-03-08 4:16 ` [PATCH 02/16] xfs: add rmap btree stats infrastructure Dave Chinner
2016-03-08 4:16 ` [PATCH 03/16] xfs: rmap btree add more reserved blocks Dave Chinner
2016-03-10 14:16 ` Christoph Hellwig
2016-03-10 14:22 ` Christoph Hellwig
2016-03-10 22:09 ` Dave Chinner [this message]
2016-03-11 7:32 ` Christoph Hellwig
2016-03-08 4:16 ` [PATCH 04/16] libxfs: rearrange xfs_bmap_add_free parameters Dave Chinner
2016-03-08 17:18 ` Christoph Hellwig
2016-03-08 4:16 ` [PATCH 05/16] xfs: add owner field to extent allocation and freeing Dave Chinner
2016-03-10 14:19 ` Christoph Hellwig
2016-03-28 22:05 ` Darrick J. Wong
2016-03-08 4:16 ` [PATCH 06/16] xfs: introduce rmap extent operation stubs Dave Chinner
2016-03-08 4:16 ` [PATCH 07/16] xfs: define the on-disk rmap btree format Dave Chinner
2016-03-08 4:16 ` [PATCH 08/16] xfs: add rmap btree growfs support Dave Chinner
2016-03-08 4:16 ` [PATCH 09/16] xfs: rmap btree transaction reservations Dave Chinner
2016-03-08 4:16 ` [PATCH 10/16] xfs: rmap btree requires more reserved free space Dave Chinner
2016-03-08 4:16 ` [PATCH 11/16] xfs: add rmap btree operations Dave Chinner
2016-03-08 4:16 ` [PATCH 12/16] xfs: add tracepoints for the rmap-mirrors-bmbt functions Dave Chinner
2016-03-08 4:16 ` [PATCH 13/16] xfs: add an extent to the rmap btree Dave Chinner
2016-03-08 4:16 ` [PATCH 14/16] xfs: remove an extent from " Dave Chinner
2016-03-08 4:16 ` [PATCH 15/16] xfs: add rmap btree insert and delete helpers Dave Chinner
2016-03-08 4:16 ` [PATCH 16/16] xfs: piggyback rmapbt update intents in the bmap free structure Dave Chinner
2016-04-11 23:23 ` Darrick J. Wong
2016-03-10 14:14 ` [PATCH 0/16] xfs: first part of rmapbt functionality Christoph Hellwig
2016-03-10 16:57 ` Darrick J. Wong
2016-03-10 21:44 ` Dave Chinner
2016-03-25 23:00 ` 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=20160310220945.GY30721@dastard \
--to=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=xfs@oss.sgi.com \
/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