diff options
author | Dave Chinner <dchinner@redhat.com> | 2012-06-22 18:50:07 +1000 |
---|---|---|
committer | Ben Myers <bpm@sgi.com> | 2012-07-01 14:50:04 -0500 |
commit | 77c1a08fc9ece4cb130b9fd279738e799f0c2864 (patch) | |
tree | 1f22efa502d7bfbd7a38a238cd1a09730548cba7 /fs/xfs/xfs_aops.h | |
parent | 9a8d2fdbb47aaa1eaa136b89da5e5e6b60015c78 (diff) | |
download | blackbird-op-linux-77c1a08fc9ece4cb130b9fd279738e799f0c2864.tar.gz blackbird-op-linux-77c1a08fc9ece4cb130b9fd279738e799f0c2864.zip |
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>
Diffstat (limited to 'fs/xfs/xfs_aops.h')
0 files changed, 0 insertions, 0 deletions