[PATCH 02/10] xfs: separate buffer indexing from block map

Mark Tinguely tinguely at sgi.com
Mon Apr 30 14:28:44 CDT 2012


On 04/24/12 01:33, Dave Chinner wrote:
> From: Dave Chinner<dchinner at redhat.com>
>
> To support discontiguous buffers in the buffer cache, we need to
> separate the cache index variables from the I/O map. While this is
> currently a 1:1 mapping, discontiguous buffer support will break
> this relationship.
>
> However, for caching purposes, we can still treat them the same as a
> contiguous buffer - the block number of the first block and the
> length of the buffer - as that is still a unique representation.
> Also, the only way we will ever access the discontiguous regions of
> buffers is via bulding the complete buffer in the first place, so
> using the initial block number and entire buffer length is a sane
> way to index the buffers.
>
> Add a block mapping vector construct to the xfs_buf and use it in
> the places where we are doing IO instead of the current
> b_bn/b_length variables.
>
> Signed-off-by: Dave Chinner<dchinner at redhat.com>
...
> +struct xfs_buf_map {
> +	xfs_daddr_t		bm_bn;	/* block number for I/O */
> +	int			bm_len;	/* size of I/O */
> +};
> +
>   typedef struct xfs_buf {
>   	/*
>   	 * first cacheline holds all the fields needed for an uncontended cache
> @@ -107,7 +114,7 @@ typedef struct xfs_buf {
>   	 * fast-path on locking.
>   	 */
>   	struct rb_node		b_rbnode;	/* rbtree node */
> -	xfs_daddr_t		b_bn;		/* block number for I/O */
> +	xfs_daddr_t		b_bn;		/* block number of buffer */
>   	int			b_length;	/* size of buffer in BBs */

Looks good.
Do you plan to eventually remove b_bn and b_length from xfs_buf?

Reviewed-by: Mark Tinguely <tinguely at sgi.com>



More information about the xfs mailing list