All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Elder <aelder@sgi.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 01/11] xfs: reshuffle dir2 headers
Date: Mon, 11 Jul 2011 17:32:40 -0500	[thread overview]
Message-ID: <1310423560.7019.53.camel@doink> (raw)
In-Reply-To: <20110710205016.890382263@bombadil.infradead.org>

On Sun, 2011-07-10 at 16:49 -0400, Christoph Hellwig wrote:
> Replace the current mess of dir2 headers with just three that have a clear
> purpose:
> 
>  - xfs_dir2_format.h for all format defintions, including the inline helpers
                                      definitions
>    to access our variable size structures
>  - xfs_dir2_priv.h for all prototypes that are internal to the dir2 code
>    and no needed by anything outside of the directory code.  For this
        not
>    purpose xfs_da_btree.c, and phase6.c in xfs_repair are considered part
>    of the directory code.
>  - xfs_dir2.h for the public interface to the directory code
> 
> In addition to the reshuffle I have also update the comments to not only
> match the new file structure, but also to describe the directory format
> better.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>

OK, I looked over this probably more closely than necessary.
In any case, it all looks good, but I'll mention just a few
things, but really they're mostly curiosity and observations
rather than anything all that pressing.
- It looks like the three files are:
    - external interface (just function prototypes)
    - internal interface (just function prototypes)
    - structures and accessors, other types, and constants
  Did it just happen to turn out that that the two interface
  files had nothing but prototypes?  Or was that what you
  intended to do?
- The contents of "xfs_dir2_format.h" comprise more than
  just the on-disk format, it really seems to capture all
  substantive data types and definitions related to directory
  structures in XFS.  
- None of the dir2 header files themselves #included
  anything else.  The same is true for your (new) three
  header files.  However, the internal interface file
  (xfs_dir2_priv.h) seems to *always* require the data
  types file (xfs_dir2_format.h) to be included first.
  What are your thoughts about just putting the #include
  of "xfs_dir2_format.h" into "xfs_dir2_priv.h".  I
  realize that's really a philosophical question, broader
  than this particular case.

A few other details, below.  I'll look for whatever your
response is, but I found no real problems and I trust
you'll do what you think is best with my suggestions here.

Reviewed-by: Alex Elder <aelder@sgi.com>

. . .

> Index: xfs/fs/xfs/xfs_dir2_format.h
> ===================================================================
> --- /dev/null	1970-01-01 00:00:00.000000000 +0000
> +++ xfs/fs/xfs/xfs_dir2_format.h	2011-07-09 13:29:33.488251514 +0200
> @@ -0,0 +1,602 @@
> +/*
> + * Copyright (c) 2000-2001,2005 Silicon Graphics, Inc.

. . .

> + * Directory version 2.
> + *
> + * There are 4 possible formats:
> + *  - shortform - embedded into the inode
> + *  - single block - data with embedded leaf at the end
> + *  - multiple data blocks, single leaf+freeindex block
> + *  - data blocks, node and leaf blocks (btree), freeindex blocks
> + *
> + * Note: many node blocks structures and constants are shared with the attributes
> + * code and defined in xfs_da_btree.h.
> + */
> +
> +#define	XFS_DIR2_BLOCK_MAGIC	0x58443242	/* XD2B: for one block dirs */
                                      /* XD2B: for single block dirs */

> +#define	XFS_DIR2_DATA_MAGIC	0x58443244	/* XD2D: for multiblock dirs */
> +#define	XFS_DIR2_FREE_MAGIC	0x58443246	/* XD2F */
                                      /* XD2F: for free index blocks */

> +
> +/*
> + * Byte offset in data block and shortform entry.
> + */
> +typedef	__uint16_t	xfs_dir2_data_off_t;

. . .

> +
> +typedef union {
> +	xfs_dir2_ino8_t	i8;
> +	xfs_dir2_ino4_t	i4;
> +} xfs_dir2_inou_t;
> +#define	XFS_DIR2_MAX_SHORT_INUM	((xfs_ino_t)0xffffffffULL)

I know this is historical, but I don't like the use of
"SHORT" here to mean "4-byte," since "short" in the
context of directories has a very different meaning
(i.e., shortform).

> +
> +/*
> + * Directory layout when stored internal to an inode.
> + *
> + * Small directories are packed as tightly as possible so as to fit into the
> + * literal area of the inode.  They consist of a single xfs_dir2_sf_hdr header
        ...of the inode.  These "shortform" directories consist...

> + * followed by zero or more xfs_dir2_sf_entry structures.  Due the different
> + * inode number storage size and the variable length name field in
> + * the xfs_dir2_sf_entry all these structure are variable length, and the
> + * accessors in this file should be used to iterate over them.
> + *
> + *
> + * The parent directory has a dedicated field, and the self-pointer must
> + * be calculated on the fly.

This sentence is not very meaningful standing by itself here.
I think it either needs a bit more context, or maybe it can
just be removed.

> + *
> + * Entries are packed toward the top as tightly as possible, and thus may
> + * be misaligned.  Care needs to be taken to access them through special
> + * helpers or copy them into aligned variables first.

Can this last sentence just be deleted, since above you
now say that the accessors here should be used?

> + */
> +typedef struct xfs_dir2_sf_hdr {
> +	__uint8_t		count;		/* count of entries */
> +	__uint8_t		i8count;	/* count of 8-byte inode #s */
> +	xfs_dir2_inou_t		parent;		/* parent dir inode number */
> +} __arch_pack xfs_dir2_sf_hdr_t;

. . .

> + *    | xfs_dir2_data_entry_t OR xfs_dir2_data_unused_t |
> + *    | xfs_dir2_data_entry_t OR xfs_dir2_data_unused_t |
> + *    | ...                                             |
> + *    +-------------------------------------------------+
> + *    | unused space                                    |
> + *    +-------------------------------------------------+
> + *
> + * As all the entries are variable size structures the accessors below should
> + * be used to iterate over them.
> + *
> + * In addition to the pure data blocks for the data and node formats it,
                                                    and node formats,

> + * most structures are also used for the combined data/freespace "block"

. . .

> + *    +---------------------------+
> + *    | xfs_dir2_leaf_tail_t      |
> + *    +---------------------------+
> + *
> + * The xfs_dir2_data_off_t members (bests) and tail are at the end of the block
> + * for single-leaf (magic = XFS_DIR2_LEAF1_MAGIC) blocks only, but not present
> + * for directories with separate leaf nodes and free space blocks
> + * (magic = XFS_DIR2_LEAFN_MAGIC).

This was nicely reworded.  Not a lot different, but better.

. . .
> + * Leaf block.
> + */
> +typedef struct xfs_dir2_leaf {
> +	xfs_dir2_leaf_hdr_t	hdr;		/* leaf header */
> +	xfs_dir2_leaf_entry_t	ents[];	/* entries */
                                        ^^^ insert a tab here

> +} xfs_dir2_leaf_t;
> +

. . .

That's it.


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

  reply	other threads:[~2011-07-11 22:32 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-10 20:49 [PATCH 00/11] a few more cleanups for Linux 3.1 Christoph Hellwig
2011-07-10 20:49 ` [PATCH 01/11] xfs: reshuffle dir2 headers Christoph Hellwig
2011-07-11 22:32   ` Alex Elder [this message]
2011-07-12  9:06     ` Christoph Hellwig
2011-07-10 20:49 ` [PATCH 02/11] xfs: cleanup struct xfs_dir2_free Christoph Hellwig
2011-07-11 22:32   ` Alex Elder
2011-07-10 20:49 ` [PATCH 03/11] xfs: factor out xfs_dir2_leaf_find_stale Christoph Hellwig
2011-07-11 22:32   ` Alex Elder
2011-07-12  9:09     ` Christoph Hellwig
2011-07-13  6:49     ` Dave Chinner
2011-07-13  7:16       ` Christoph Hellwig
2011-07-13 10:28         ` Dave Chinner
2011-07-10 20:49 ` [PATCH 04/11] xfs: factor out xfs_da_grow_inode_int Christoph Hellwig
2011-07-11  0:37   ` Dave Chinner
2011-07-11  5:24     ` Christoph Hellwig
2011-07-12  0:55       ` Dave Chinner
2011-07-11 22:32   ` Alex Elder
2011-07-10 20:49 ` [PATCH 05/11] xfs: add a proper transaction pointer to struct xfs_buf Christoph Hellwig
2011-07-11 22:33   ` Alex Elder
2011-07-12  9:12     ` Christoph Hellwig
2011-07-10 20:49 ` [PATCH 06/11] xfs: remove wrappers around b_fspriv Christoph Hellwig
2011-07-11 22:33   ` Alex Elder
2011-07-12  1:02     ` Dave Chinner
2011-07-12  9:15       ` Christoph Hellwig
2011-07-10 20:49 ` [PATCH 07/11] xfs: remove wrappers around b_iodone Christoph Hellwig
2011-07-11 22:33   ` Alex Elder
2011-07-10 20:49 ` [PATCH 08/11] xfs: remove the unused xfs_buf_delwri_sort function Christoph Hellwig
2011-07-11 22:33   ` Alex Elder
2011-07-10 20:49 ` [PATCH 09/11] xfs: remove the dead QUOTADEBUG debug Christoph Hellwig
2011-07-11 22:33   ` Alex Elder
2011-07-12  0:59     ` Dave Chinner
2011-07-10 20:49 ` [PATCH 10/11] xfs: remove leftovers of the old btree tracing code Christoph Hellwig
2011-07-12  2:52   ` Alex Elder
2011-07-10 20:49 ` [PATCH 11/11] xfs: kill the dead XFS_DABUF debug code Christoph Hellwig
2011-07-11 22:33   ` Alex Elder
2011-07-13  6:51 ` [PATCH 00/11] a few more cleanups for Linux 3.1 Dave Chinner

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=1310423560.7019.53.camel@doink \
    --to=aelder@sgi.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.