From: Christoph Hellwig <hch@infradead.org>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 9/9] xfs: factor buffer reading from xfs_dir2_leaf_getdents
Date: Wed, 20 Jun 2012 03:27:10 -0400 [thread overview]
Message-ID: <20120620072709.GA27358@infradead.org> (raw)
In-Reply-To: <1339133914-11148-10-git-send-email-david@fromorbit.com>
> +struct _map_info {
> + xfs_bmbt_irec_t *map; /* map vector for blocks */
> + xfs_extlen_t map_blocks; /* number of fsbs in map */
> + xfs_dablk_t map_off; /* last mapped file offset */
> + int map_size; /* total entries in *map */
> + int map_valid; /* valid entries in *map */
> + int nmap; /* mappings to ask xfs_bmapi */
> + xfs_dir2_db_t curdb; /* db for current block */
> +};
> +
> +struct _ra_info {
Can you give these structure names xfs_dir2_leaf prefixes, please?
Also any reason the ra_info structure is kept entirely separate? While
I see a bit of a point to have a logical grouping, it still semes more
useful to just embedd it into the map_info.
> + map_info.map_size = howmany(bufsize + mp->m_dirblksize,
> + mp->m_sb.sb_blocksize);
> + map_info.map = kmem_zalloc(map_info.map_size *
> + sizeof(struct xfs_bmbt_irec), KM_SLEEP);
I'd be tempted to say that the map field in the map_info should be a
variable sized array the end, and the whole structure should be
dynamically allocated to get a couple more variables off the stack.
Except for these nitpicks this looks like a great cleanup to me.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2012-06-20 7:27 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-08 5:38 [PATCH 0/9] xfs: discontiguous directory buffer support Dave Chinner
2012-06-08 5:38 ` [PATCH 1/9] xfs: separate buffer indexing from block map Dave Chinner
2012-06-18 20:39 ` Ben Myers
2012-06-20 6:44 ` Christoph Hellwig
2012-06-20 7:36 ` Dave Chinner
2012-06-08 5:38 ` [PATCH 2/9] xfs: convert internal buffer functions to pass maps Dave Chinner
2012-06-18 20:43 ` Ben Myers
2012-06-18 21:07 ` Ben Myers
2012-06-19 7:15 ` Christoph Hellwig
2012-06-19 15:59 ` Ben Myers
2012-06-19 17:03 ` Christoph Hellwig
2012-06-19 17:11 ` Ben Myers
2012-06-20 5:56 ` Dave Chinner
2012-06-20 6:04 ` Christoph Hellwig
2012-06-20 6:29 ` Dave Chinner
2012-06-20 6:46 ` Dave Chinner
2012-06-20 15:39 ` Ben Myers
2012-06-20 15:36 ` Ben Myers
2012-06-20 23:04 ` Dave Chinner
2012-06-20 6:35 ` Dave Chinner
2012-06-20 15:48 ` Ben Myers
2012-06-20 6:29 ` Christoph Hellwig
2012-06-20 6:37 ` Dave Chinner
2012-06-20 15:51 ` Ben Myers
2012-06-20 6:48 ` Christoph Hellwig
2012-06-22 6:48 ` Dave Chinner
2012-06-08 5:38 ` [PATCH 3/9] xfs: add discontiguous buffer map interface Dave Chinner
2012-06-20 6:53 ` Christoph Hellwig
2012-06-08 5:38 ` [PATCH 4/9] xfs: add discontiguous buffer support to transactions Dave Chinner
2012-06-20 6:54 ` Christoph Hellwig
2012-06-08 5:38 ` [PATCH 5/9] xfs: struct xfs_buf_log_format isn't variable sized Dave Chinner
2012-06-20 6:36 ` Christoph Hellwig
2012-06-20 7:01 ` Dave Chinner
2012-06-20 7:05 ` Christoph Hellwig
2012-06-08 5:38 ` [PATCH 6/9] xfs: support discontiguous buffers in the xfs_buf_log_item Dave Chinner
2012-06-20 7:15 ` Christoph Hellwig
2012-06-08 5:38 ` [PATCH 7/9] xfs: use multiple irec xfs buf support in dabuf Dave Chinner
2012-06-20 7:18 ` Christoph Hellwig
2012-06-08 5:38 ` [PATCH 8/9] xfs: remove struct xfs_dabuf and infrastructure Dave Chinner
2012-06-20 7:20 ` Christoph Hellwig
2012-06-08 5:38 ` [PATCH 9/9] xfs: factor buffer reading from xfs_dir2_leaf_getdents Dave Chinner
2012-06-20 7:27 ` Christoph Hellwig [this message]
2012-06-20 7:41 ` Dave Chinner
-- strict thread matches above, loose matches on Subject: below --
2012-06-22 8:50 [PATCH 0/9, V2] xfs; discontiguous buffer support Dave Chinner
2012-06-22 8:50 ` [PATCH 9/9] xfs: factor buffer reading from xfs_dir2_leaf_getdents Dave Chinner
2012-06-26 10:16 ` 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=20120620072709.GA27358@infradead.org \
--to=hch@infradead.org \
--cc=david@fromorbit.com \
--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 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.