From: Brian Foster <bfoster@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH v3 08/18] xfs: helpers to convert holemask to/from generic bitmap
Date: Mon, 9 Feb 2015 10:15:21 -0500 [thread overview]
Message-ID: <20150209151521.GC18336@laptop.bfoster> (raw)
In-Reply-To: <20150208235448.GI4251@dastard>
On Mon, Feb 09, 2015 at 10:54:48AM +1100, Dave Chinner wrote:
> On Fri, Feb 06, 2015 at 02:52:55PM -0500, Brian Foster wrote:
> > 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_ialloc.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 69 insertions(+)
> >
> > diff --git a/fs/xfs/libxfs/xfs_ialloc.c b/fs/xfs/libxfs/xfs_ialloc.c
> > index 72ade0e..fc001d9 100644
> > --- a/fs/xfs/libxfs/xfs_ialloc.c
> > +++ b/fs/xfs/libxfs/xfs_ialloc.c
> > @@ -39,6 +39,8 @@
> > #include "xfs_icache.h"
> > #include "xfs_trace.h"
> >
> > +STATIC void
> > +xfs_inobt_ialloc_bitmap(unsigned long *, struct xfs_inobt_rec_incore *);
>
> xfs_inobt_irec_to_allocmap() seems more appropriate for what it does.
> I'd also suggest it should be in xfs_ialloc_btree.c, too.
>
Ok.
> > /*
> > * Allocation group level functions.
> > @@ -739,6 +741,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);
> > +}
>
> Ok, so this is for doing logic operations on the bitmap, such as
> inverting or masking out a bunch of bits?
>
Yes, generally to convert to inode granularity for whatever operations
require it (e.g., find a "real" free inode from ir_free).
> The first use of this function is xfs_inobt_first_free_inode(), and
> the other use is in xfs_difree_inobt() to build the mask of inodes
> in the chunk that need to be freed, and in both those cases they do
>
> xfs_inobt_ialloc_bitmap(alloc, rec)
> allocmask = bitmap_to_u64(alloc, 64);
>
> and the local stack bitmap is otherwise unused. So, wouldn't a
> helper like:
>
> /*
> * Return a host format mask of all the allocated inodes in the
> * chunk. The bitmap format depends on the native word size (e.g.
> * see arch/powerpc/include/asm/bitops.h) and so we have to marshall
> * the bitmap through a defined endian conversion so that we can
> * perform host native 64 bit logic operations on the resultant
> * allocation mask.
> *
> * A bit value of 1 means the inode is allocated, a value of 0 means it
> * is free.
> */
> u64
> xfs_inobt_irec_to_allocmask(
> struct xfs_inobt_rec_incore *irec)
> {
> DECLARE_BITMAP(allocmap, 64),
> __le64 lebitmap;
>
> xfs_inobt_rec_to_allocmap(&allocmap, irec);
> bitmap_copy_le(&lebitmap, allocmap, 64);
> return le64_to_cpu(lebitmap);
> }
>
Yeah, I went back and forth with doing the conversion within the
original helper. We ultimately end up with a couple more callers that do
use the generic bitmap, but this could be helpful to those that don't.
> > +
> > +/*
> > + * 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.
>
> " a bit value of 1 means the inode is allocated, a value of 0 means
> it is free"
>
Ok.
> > + */
> > +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]));
>
> BUILD_BUG_ON(sizeof(rec->ir_holemask) <= sizeof(holemask[0]));
>
> i.e. if we come across a platform where this fails, break the build
> rather than waiting for the unlikely event of someone running a
> debug kernel on that platform...
>
I assume the logic has to be inverted, but otherwise that's probably a
better idea. Thanks.
Brian
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2015-02-09 16:04 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-06 19:52 [PATCH v3 00/18] xfs: sparse inode chunks Brian Foster
2015-02-06 19:52 ` [PATCH v3 01/18] xfs: add sparse inode chunk alignment superblock field Brian Foster
2015-02-06 22:40 ` Dave Chinner
2015-02-08 16:04 ` Brian Foster
2015-02-08 21:43 ` Dave Chinner
2015-02-06 19:52 ` [PATCH v3 02/18] xfs: use sparse chunk alignment for min. inode allocation requirement Brian Foster
2015-02-06 19:52 ` [PATCH v3 03/18] xfs: sparse inode chunks feature helpers and mount requirements Brian Foster
2015-02-06 22:54 ` Dave Chinner
2015-02-06 19:52 ` [PATCH v3 04/18] xfs: introduce inode record hole mask for sparse inode chunks Brian Foster
2015-02-06 23:16 ` Dave Chinner
2015-02-08 16:06 ` Brian Foster
2015-02-08 21:57 ` Dave Chinner
2015-02-09 15:15 ` Brian Foster
2015-02-09 21:48 ` Dave Chinner
2015-02-10 12:58 ` Brian Foster
2015-02-06 19:52 ` [PATCH v3 05/18] xfs: create macros/helpers for dealing with " Brian Foster
2015-02-06 19:52 ` [PATCH v3 06/18] xfs: pass inode count through ordered icreate log item Brian Foster
2015-02-06 19:52 ` [PATCH v3 07/18] xfs: handle sparse inode chunks in icreate log recovery Brian Foster
2015-02-06 23:19 ` Dave Chinner
2015-02-08 16:06 ` Brian Foster
2015-02-06 19:52 ` [PATCH v3 08/18] xfs: helpers to convert holemask to/from generic bitmap Brian Foster
2015-02-08 23:54 ` Dave Chinner
2015-02-09 15:15 ` Brian Foster [this message]
2015-02-06 19:52 ` [PATCH v3 09/18] xfs: support min/max agbno args in block allocator Brian Foster
2015-02-09 0:01 ` Dave Chinner
2015-02-06 19:52 ` [PATCH v3 10/18] xfs: allocate sparse inode chunks on full chunk allocation failure Brian Foster
2015-02-09 1:25 ` Dave Chinner
2015-02-09 15:20 ` Brian Foster
2015-02-06 19:52 ` [PATCH v3 11/18] xfs: randomly do sparse inode allocations in DEBUG mode Brian Foster
2015-02-08 23:02 ` Dave Chinner
2015-02-09 15:20 ` Brian Foster
2015-02-06 19:52 ` [PATCH v3 12/18] xfs: filter out sparse regions from individual inode allocation Brian Foster
2015-02-08 22:49 ` Dave Chinner
2015-02-06 19:53 ` [PATCH v3 13/18] xfs: update free inode record logic to support sparse inode records Brian Foster
2015-02-08 22:33 ` Dave Chinner
2015-02-06 19:53 ` [PATCH v3 14/18] xfs: only free allocated regions of inode chunks Brian Foster
2015-02-06 19:53 ` [PATCH v3 15/18] xfs: skip unallocated regions of inode chunks in xfs_ifree_cluster() Brian Foster
2015-02-06 19:53 ` [PATCH v3 16/18] xfs: use actual inode count for sparse records in bulkstat/inumbers Brian Foster
2015-02-08 22:29 ` Dave Chinner
2015-02-06 19:53 ` [PATCH v3 17/18] xfs: add fs geometry bit for sparse inode chunks Brian Foster
2015-02-06 19:53 ` [PATCH v3 18/18] 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=20150209151521.GC18336@laptop.bfoster \
--to=bfoster@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox