]> git.kernelconcepts.de Git - karo-tx-linux.git/commit
xfs: struct xfs_buf_log_format isn't variable sized.
authorDave Chinner <dchinner@redhat.com>
Fri, 22 Jun 2012 08:50:07 +0000 (18:50 +1000)
committerBen Myers <bpm@sgi.com>
Sun, 1 Jul 2012 19:50:04 +0000 (14:50 -0500)
commit77c1a08fc9ece4cb130b9fd279738e799f0c2864
tree1f22efa502d7bfbd7a38a238cd1a09730548cba7
parent9a8d2fdbb47aaa1eaa136b89da5e5e6b60015c78
xfs: struct xfs_buf_log_format isn't variable sized.

The struct xfs_buf_log_format wants to think the dirty bitmap is
variable sized.  In fact, it is variable size on disk simply due to
the way we map it from the in-memory structure, but we still just
use a fixed size memory allocation for the in-memory structure.

Hence it makes no sense to set the function up as a variable sized
structure when we already know it's maximum size, and we always
allocate it as such. Simplify the structure by making the dirty
bitmap a fixed sized array and just using the size of the structure
for the allocation size.

This will make it much simpler to allocate and manipulate an array
of format structures for discontiguous buffer support.

The previous struct xfs_buf_log_item size according to
/proc/slabinfo was 224 bytes. pahole doesn't give the same size
because of the variable size definition. With this modification,
pahole reports the same as /proc/slabinfo:

/* size: 224, cachelines: 4, members: 6 */

Because the xfs_buf_log_item size is now determined by the maximum
supported block size we introduce a dependency on xfs_alloc_btree.h.
Avoid this dependency by moving the idefines for the maximum block
sizes supported to xfs_types.h with all the other max/min type
defines to avoid any new dependencies.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ben Myers <bpm@sgi.com>
fs/xfs/xfs_alloc_btree.h
fs/xfs/xfs_buf_item.c
fs/xfs/xfs_buf_item.h
fs/xfs/xfs_super.c
fs/xfs/xfs_types.h