public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 22/27] xfs: use generic get_unaligned_beXX helpers
Date: Wed, 6 Jul 2011 13:44:21 +1000	[thread overview]
Message-ID: <20110706034421.GQ1026@dastard> (raw)
In-Reply-To: <20110701094606.763430916@bombadil.infradead.org>

On Fri, Jul 01, 2011 at 05:43:43AM -0400, Christoph Hellwig wrote:
> Switch the shortform directory code over to use the generic
> get_unaligned_beXX helpers instead of reinventing them.  As a result
> kill off xfs_arch.h and move the setting of XFS_NATIVE_HOST into
> xfs_linux.h.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
.....
> -/*
> - * In directories inode numbers are stored as unaligned arrays of unsigned
> - * 8bit integers on disk.
> - *
> - * For v1 directories or v2 directories that contain inode numbers that
> - * do not fit into 32bit the array has eight members, but the first member
> - * is always zero:
> - *
> - *  |unused|48-55|40-47|32-39|24-31|16-23| 8-15| 0- 7|

Well, I learnt something today.

So we only support 56 bit inode numbers in shortform directories?
AFAIK, Nothing else in the code enforces this limitation. I
just found XFS_MAXINUMBER to define the maximum inode
number to be 56 bits in size, but, well, it's not used anywhere
relevant (like when initialising AGs)......

Hmmmm. I wonder if it is a hold-over from the days of 4GB AGs?
That would have meant inode numbers used 6 bits for the chunk index,
2^22 - 2^6 for the agbno and 2^32 for the agno, which gives 54 bits
maximum inode number and so XFS_MAXINUMBER @ 56 bits makes sense, as
does the zero high byte in the dir2 inode number.

Now we have 2^30 bits for the agbno+chunk index, and 32 bits for the
agno, so inode numbers can reach 62 bits, which is outside the range
of the 56-bit MAXINUMBER limit.

So my questions are now this:
	- is there any other reason for a 56 bit inode number limit?
	- why isn't it enforced for the rest of the directory code?
	- did we lose that checking when we converted the rest of
	  the directory code to use the generic byte swapping
	  functions?
	- do we need to increase XFS_MAXINUMBER to reflect the
	  current reality of 1TB AGs and simply ignore the zero high
	  byte restriction?

As it is, we need to update AG initialisation to disallow inode
allocation in AGs above the XFS_MAXINUMBER if we don't allow them in
the directory structure....


> +++ xfs/fs/xfs/xfs_dir2_sf.c	2011-06-30 20:46:45.366236141 +0200
> @@ -59,11 +59,12 @@ static void xfs_dir2_sf_toino4(xfs_da_ar
>  static void xfs_dir2_sf_toino8(xfs_da_args_t *args);
>  #endif /* XFS_BIG_INUMS */
>  
> -
>  /*
>   * Inode numbers in short-form directories can come in two versions,
>   * either 4 bytes or 8 bytes wide.  These helpers deal with the
>   * two forms transparently by looking at the headers i8count field.
> + *
> + * For 64-bit inode number the most significant byte must be zero.

This comment is what lead me one that path....

>   */
>  static xfs_ino_t
>  xfs_dir2_sf_get_ino(
> @@ -71,9 +72,9 @@ xfs_dir2_sf_get_ino(
>  	xfs_dir2_inou_t		*from)
>  {
>  	if (hdr->i8count)
> -		return XFS_GET_DIR_INO8(from->i8);
> +		return get_unaligned_be64(&from->i8.i) & 0x00ffffffffffffffULL;
>  	else
> -		return XFS_GET_DIR_INO4(from->i4);
> +		return get_unaligned_be32(&from->i4.i);
>  }
>  
>  static void
> @@ -82,10 +83,12 @@ xfs_dir2_sf_put_ino(
>  	xfs_dir2_inou_t		*to,
>  	xfs_ino_t		ino)
>  {
> +	ASSERT((ino & 0xff00000000000000ULL) == 0);
> +
>  	if (hdr->i8count)
> -		XFS_PUT_DIR_INO8(ino, to->i8);
> +		put_unaligned_be64(ino, &to->i8.i);
>  	else
> -		XFS_PUT_DIR_INO4(ino, to->i4);
> +		put_unaligned_be32(ino, &to->i4.i);
>  }
>  
>  xfs_ino_t
> Index: xfs/fs/xfs/xfs_dir2_sf.h
> ===================================================================
> --- xfs.orig/fs/xfs/xfs_dir2_sf.h	2011-06-30 20:24:08.732919663 +0200
> +++ xfs/fs/xfs/xfs_dir2_sf.h	2011-06-30 20:38:37.019575543 +0200
> @@ -95,13 +95,13 @@ static inline int xfs_dir2_sf_hdr_size(i
>  static inline xfs_dir2_data_aoff_t
>  xfs_dir2_sf_get_offset(xfs_dir2_sf_entry_t *sfep)
>  {
> -	return INT_GET_UNALIGNED_16_BE(&(sfep)->offset.i);
> +	return get_unaligned_be16(&sfep->offset.i);
>  }
>  
>  static inline void
>  xfs_dir2_sf_put_offset(xfs_dir2_sf_entry_t *sfep, xfs_dir2_data_aoff_t off)
>  {
> -	INT_SET_UNALIGNED_16_BE(&(sfep)->offset.i, off);
> +	put_unaligned_be16(off, &sfep->offset.i);
>  }
>  
>  static inline int

As a straight translation this patch is fine, but I think I'd like
to resolve some of the questions it raises first before anything
else....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2011-07-06  3:44 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-01  9:43 [PATCH 00/27] patch queue for Linux 3.1, V2 Christoph Hellwig
2011-07-01  9:43 ` [PATCH 01/27] xfs: PF_FSTRANS should never be set in ->writepage Christoph Hellwig
2011-07-01  9:43 ` [PATCH 02/27] xfs: re-enable non-blocking behaviour in xfs_map_blocks Christoph Hellwig
2011-07-05 22:35   ` Alex Elder
2011-07-06  6:37     ` Christoph Hellwig
2011-07-06 13:36       ` Alex Elder
2011-07-01  9:43 ` [PATCH 03/27] xfs: work around bogus gcc warning in xfs_allocbt_init_cursor Christoph Hellwig
2011-07-01  9:43 ` [PATCH 04/27] xfs: split xfs_setattr Christoph Hellwig
2011-07-01  9:43 ` [PATCH 06/27] xfs: kill xfs_itruncate_start Christoph Hellwig
2011-07-01  9:43 ` [PATCH 07/27] xfs: split xfs_itruncate_finish Christoph Hellwig
2011-07-06  4:35   ` Alex Elder
2011-07-06  8:11     ` Christoph Hellwig
2011-07-06 14:05       ` Alex Elder
2011-07-01  9:43 ` [PATCH 08/27] xfs: improve sync behaviour in the fact of aggressive dirtying Christoph Hellwig
2011-07-05 22:36   ` Alex Elder
2011-07-06  8:15     ` Christoph Hellwig
2011-07-06 14:59       ` Alex Elder
2011-07-01  9:43 ` [PATCH 09/27] xfs: fix filesystsem freeze race in xfs_trans_alloc Christoph Hellwig
2011-07-05 22:36   ` Alex Elder
2011-07-01  9:43 ` [PATCH 10/27] xfs: remove i_transp Christoph Hellwig
2011-07-05 22:36   ` Alex Elder
2011-07-01  9:43 ` [PATCH 11/27] xfs: kill the unused struct xfs_sync_work Christoph Hellwig
2011-07-05 22:36   ` Alex Elder
2011-07-01  9:43 ` [PATCH 12/27] xfs: factor out xfs_dir2_leaf_find_entry Christoph Hellwig
2011-07-05 22:36   ` Alex Elder
2011-07-01  9:43 ` [PATCH 13/27] xfs: cleanup shortform directory inode number handling Christoph Hellwig
2011-07-05 22:36   ` Alex Elder
2011-07-01  9:43 ` [PATCH 14/27] xfs: kill struct xfs_dir2_sf Christoph Hellwig
2011-07-06  1:57   ` Dave Chinner
2011-07-06  8:28     ` Christoph Hellwig
2011-07-06  3:24   ` Alex Elder
2011-07-06  8:33     ` Christoph Hellwig
2011-07-06 15:05       ` Alex Elder
2011-07-01  9:43 ` [PATCH 15/27] xfs: cleanup the defintion of struct xfs_dir2_sf_entry Christoph Hellwig
2011-07-06  2:00   ` Dave Chinner
2011-07-06  3:33   ` Alex Elder
2011-07-06  8:34     ` Christoph Hellwig
2011-07-01  9:43 ` [PATCH 16/27] xfs: avoid usage of struct xfs_dir2_block Christoph Hellwig
2011-07-06  2:19   ` Dave Chinner
2011-07-06  8:35     ` Christoph Hellwig
2011-07-06  3:36   ` Alex Elder
2011-07-01  9:43 ` [PATCH 17/27] xfs: kill " Christoph Hellwig
2011-07-06  2:31   ` Dave Chinner
2011-07-06  8:37     ` Christoph Hellwig
2011-07-06 15:11       ` Alex Elder
2011-07-06  3:36   ` Alex Elder
2011-07-01  9:43 ` [PATCH 18/27] xfs: avoid usage of struct xfs_dir2_data Christoph Hellwig
2011-07-06  3:02   ` Dave Chinner
2011-07-06  8:43     ` Christoph Hellwig
2011-07-06  3:38   ` Alex Elder
2011-07-06  8:45     ` Christoph Hellwig
2011-07-01  9:43 ` [PATCH 19/27] xfs: kill " Christoph Hellwig
2011-07-06  3:05   ` Dave Chinner
2011-07-06  3:38   ` Alex Elder
2011-07-01  9:43 ` [PATCH 20/27] xfs: cleanup the defintion of struct xfs_dir2_data_entry Christoph Hellwig
2011-07-06  3:06   ` Dave Chinner
2011-07-06  3:44   ` Alex Elder
2011-07-06  8:48     ` Christoph Hellwig
2011-07-01  9:43 ` [PATCH 21/27] xfs: cleanup struct xfs_dir2_leaf Christoph Hellwig
2011-07-06  3:13   ` Dave Chinner
2011-07-06  3:44   ` Alex Elder
2011-07-01  9:43 ` [PATCH 22/27] xfs: use generic get_unaligned_beXX helpers Christoph Hellwig
2011-07-06  3:44   ` Dave Chinner [this message]
2011-07-06  9:07     ` Christoph Hellwig
2011-07-07  8:00       ` Christoph Hellwig
2011-07-06  3:47   ` Alex Elder
2011-07-01  9:43 ` [PATCH 23/27] xfs: remove the unused xfs_bufhash structure Christoph Hellwig
2011-07-06  3:44   ` Dave Chinner
2011-07-06  3:49   ` Alex Elder
2011-07-01  9:43 ` [PATCH 24/27] xfs: clean up buffer locking helpers Christoph Hellwig
2011-07-06  3:47   ` Dave Chinner
2011-07-06  3:55   ` Alex Elder
2011-07-01  9:43 ` [PATCH 25/27] xfs: return the buffer locked from xfs_buf_get_uncached Christoph Hellwig
2011-07-06  3:48   ` Dave Chinner
2011-07-06  3:57   ` Alex Elder
2011-07-01  9:43 ` [PATCH 26/27] xfs: cleanup I/O-related buffer flags Christoph Hellwig
2011-07-06  3:54   ` Dave Chinner
2011-07-06  9:11     ` Christoph Hellwig
2011-07-06  4:09   ` Alex Elder
2011-07-06  9:11     ` Christoph Hellwig
2011-07-01  9:43 ` [PATCH 27/27] xfs: avoid a few disk cache flushes Christoph Hellwig
2011-07-06  3:55   ` Dave Chinner
2011-07-06  4:11   ` Alex Elder
2011-07-06  4:40 ` [PATCH 00/27] patch queue for Linux 3.1, V2 Alex Elder
2011-07-06  6:42   ` Christoph Hellwig
2011-07-06 13:32     ` Alex Elder
2011-07-06 13:43       ` 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=20110706034421.GQ1026@dastard \
    --to=david@fromorbit.com \
    --cc=hch@infradead.org \
    --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