From: Brian Foster <bfoster@redhat.com>
To: xfs@oss.sgi.com
Subject: [PATCH v2 10/17] xfs: helpers to convert holemask to/from generic bitmap
Date: Mon, 3 Nov 2014 11:12:19 -0500 [thread overview]
Message-ID: <1415031146-9107-11-git-send-email-bfoster@redhat.com> (raw)
In-Reply-To: <1415031146-9107-1-git-send-email-bfoster@redhat.com>
The inobt record holemask field is a condensed data type designed to fit
into the existing on-disk record and is zero based (allocated regions
are set to 0, sparse regions are set to 1) to provide backwards
compatibility. This makes the type somewhat complex for use in higher
level inode manipulations such as individual inode allocation, etc.
Rather than foist the complexity of dealing with this field to every bit
of logic that requires inode granular information, create the
xfs_inobt_ialloc_bitmap() helper to convert the holemask to an inode
allocation bitmap. The inode allocation bitmap is inode granularity
similar to the inobt record free mask and indicates which inodes of the
chunk are physically allocated on disk, irrespective of whether the
inode is considered allocated or free by the filesystem. The generic
bitmap type requires the use of generic kernel bitmap APIs.
The bitmap_to_u64() helper is provided to convert the bitmap back to a
native 64-bit type (for native bitwise operations). This is required
because the generic bitmap code represents a bitmap as an array of
unsigned long in a little endian style (though each array value is cpu
order). To ensure compatibility with various word sizes and endianness',
bitmap_to_u64() exports the bitmap to little endian and swaps back to
cpu byte order.
Signed-off-by: Brian Foster <bfoster@redhat.com>
---
fs/xfs/libxfs/xfs_format.h | 1 +
fs/xfs/libxfs/xfs_ialloc.c | 67 ++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 68 insertions(+)
diff --git a/fs/xfs/libxfs/xfs_format.h b/fs/xfs/libxfs/xfs_format.h
index c81c1a7..f2ff6d5 100644
--- a/fs/xfs/libxfs/xfs_format.h
+++ b/fs/xfs/libxfs/xfs_format.h
@@ -202,6 +202,7 @@ typedef __be32 xfs_alloc_ptr_t;
#define XFS_FIBT_CRC_MAGIC 0x46494233 /* 'FIB3' */
typedef __uint64_t xfs_inofree_t;
+typedef __uint64_t xfs_inoalloc_t;
#define XFS_INODES_PER_CHUNK (NBBY * sizeof(xfs_inofree_t))
#define XFS_INODES_PER_CHUNK_LOG (XFS_NBBYLOG + 3)
#define XFS_INOBT_ALL_FREE ((xfs_inofree_t)-1)
diff --git a/fs/xfs/libxfs/xfs_ialloc.c b/fs/xfs/libxfs/xfs_ialloc.c
index d22dd8a..88ca72f 100644
--- a/fs/xfs/libxfs/xfs_ialloc.c
+++ b/fs/xfs/libxfs/xfs_ialloc.c
@@ -910,6 +910,73 @@ xfs_ialloc_get_rec(
return 0;
}
+static inline uint64_t
+bitmap_to_u64(
+ const unsigned long *bitmap,
+ int nbits)
+{
+ __le64 lebitmap;
+
+ ASSERT(nbits <= 64);
+
+ /*
+ * The bitmap format depends on the native word size. E.g., bit 0 could
+ * land in the middle of the 64 bits on a big endian 32-bit arch (see
+ * arch/powerpc/include/asm/bitops.h). To handle this, export the bitmap
+ * as 64-bit little endian and convert back to native byte order.
+ */
+ bitmap_copy_le(&lebitmap, bitmap, nbits);
+ return le64_to_cpu(lebitmap);
+}
+
+/*
+ * Convert the inode record holemask to an inode allocation bitmap. The inode
+ * allocation bitmap is inode granularity and specifies whether an inode is
+ * physically allocated on disk (not whether the inode is considered allocated
+ * or free by the fs).
+ *
+ * We have to be careful with regard to byte order and word size since the
+ * generic bitmap code uses primitive types.
+ */
+STATIC void
+xfs_inobt_ialloc_bitmap(
+ unsigned long *allocbmap,
+ struct xfs_inobt_rec_incore *rec)
+{
+ int nextbit;
+ DECLARE_BITMAP(holemask, 16);
+
+ bitmap_zero(allocbmap, 64);
+
+ /*
+ * bitmaps are represented as an array of unsigned long (each in cpu
+ * byte order). ir_holemask is only 16 bits, so direct assignment is
+ * safe.
+ */
+ ASSERT(sizeof(rec->ir_holemask) <= sizeof(holemask[0]));
+ holemask[0] = rec->ir_holemask;
+
+ /*
+ * holemask is a 16-bit bitmap and inode records span 64 inodes. Thus
+ * each holemask bit represents multiple (XFS_INODES_PER_HOLEMASK_BIT)
+ * inodes. Since holemask bits represent holes, each set bit represents
+ * a region of the physical chunk that is not tracked by the record.
+ *
+ * We want an inode granularity allocation bitmap. We have to invert the
+ * holemask and set XFS_INODES_PER_HOLEMASK_BIT bits for each set bit.
+ * We invert and expand simultaneously by walking the unset (zeroed)
+ * holemask bits. For each zero bit in holemask, set the corresponding
+ * XFS_INODES_PER_HOLEMASK_BIT bits in the allocation bitmap.
+ */
+ nextbit = find_first_zero_bit(holemask, 16);
+ while (nextbit < 16) {
+ bitmap_set(allocbmap, nextbit * XFS_INODES_PER_HOLEMASK_BIT,
+ XFS_INODES_PER_HOLEMASK_BIT);
+
+ nextbit = find_next_zero_bit(holemask, 16, nextbit + 1);
+ }
+}
+
/*
* Allocate an inode using the inobt-only algorithm.
*/
--
1.8.3.1
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-11-03 16:12 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-03 16:12 [PATCH v2 00/17] xfs: sparse inode chunks Brian Foster
2014-11-03 16:12 ` [PATCH v2 01/17] xfs: add sparse inode chunk alignment superblock field Brian Foster
2014-11-03 16:12 ` [PATCH v2 02/17] xfs: use sparse chunk alignment for min. inode allocation requirement Brian Foster
2014-11-03 16:12 ` [PATCH v2 03/17] xfs: define sparse inode chunks v5 sb feature bit and helper function Brian Foster
2014-11-03 16:12 ` [PATCH v2 04/17] xfs: introduce inode record hole mask for sparse inode chunks Brian Foster
2014-11-03 16:12 ` [PATCH v2 05/17] xfs: create macros/helpers for dealing with " Brian Foster
2014-11-03 22:12 ` Fanael Linithien
2014-11-03 22:34 ` Brian Foster
2014-11-03 23:56 ` Fanael Linithien
2014-11-04 1:33 ` Dave Chinner
2014-11-04 12:15 ` Brian Foster
2014-11-04 12:14 ` Brian Foster
2014-11-03 16:12 ` [PATCH v2 06/17] xfs: pass inode count through ordered icreate log item Brian Foster
2014-11-03 16:12 ` [PATCH v2 07/17] xfs: handle sparse inode chunks in icreate log recovery Brian Foster
2014-11-03 16:12 ` [PATCH v2 08/17] xfs: create helper to manage record overlap for sparse inode chunks Brian Foster
2014-11-03 16:12 ` [PATCH v2 09/17] xfs: allocate sparse inode chunks on full chunk allocation failure Brian Foster
2014-11-03 16:12 ` Brian Foster [this message]
2014-11-03 16:12 ` [PATCH v2 11/17] xfs: filter out sparse regions from individual inode allocation Brian Foster
2014-11-03 16:12 ` [PATCH v2 12/17] xfs: update free inode record logic to support sparse inode records Brian Foster
2014-11-03 16:12 ` [PATCH v2 13/17] xfs: only free allocated regions of inode chunks Brian Foster
2014-11-03 16:12 ` [PATCH v2 14/17] xfs: skip unallocated regions of inode chunks in xfs_ifree_cluster() Brian Foster
2014-11-03 16:12 ` [PATCH v2 15/17] xfs: use actual inode count for sparse records in bulkstat/inumbers Brian Foster
2014-11-03 16:12 ` [PATCH v2 16/17] xfs: add fs geometry bit for sparse inode chunks Brian Foster
2014-11-03 16:12 ` [PATCH v2 17/17] xfs: enable sparse inode chunks for v5 superblocks Brian Foster
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=1415031146-9107-11-git-send-email-bfoster@redhat.com \
--to=bfoster@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox