[lustre-devel] [PATCH 01/28] lustre: pfl: Basic data structures for composite layout

From: Patrick Farrell <paf@cray.com>
To: lustre-devel@lists.lustre.org
Subject: [lustre-devel] [PATCH 01/28] lustre: pfl: Basic data structures for composite layout
Date: Tue, 18 Dec 2018 01:47:41 +0000	[thread overview]
Message-ID: <MWHPR11MB1488860506C8F6D1CCE8541FCBBD0@MWHPR11MB1488.namprd11.prod.outlook.com> (raw)
In-Reply-To: <87va3raev2.fsf@notabene.neil.brown.name>

Re: KNOWN.

These are on disk flags.  It?s a mask used to check for unknown flags.

________________________________
From: lustre-devel <lustre-devel-bounces@lists.lustre.org> on behalf of NeilBrown <neilb@suse.com>
Sent: Monday, December 17, 2018 5:54:41 PM
To: James Simmons; Andreas Dilger; Oleg Drokin; Bobi Jam; Jinshan Xiong
Cc: Lustre Development List
Subject: Re: [lustre-devel] [PATCH 01/28] lustre: pfl: Basic data structures for composite layout

On Mon, Dec 17 2018, James Simmons wrote:

> From: Niu Yawei <yawei.niu@intel.com>
>
> Added basic structures and magic numbers for composite layout.
>

This would be a great place to (brief) explain what PFL does and what it
is going to do with this data structures.
What are the "components" and how do they form a "composite layout" ??

> +
> +enum lov_comp_md_entry_flags {
> +     LCME_FL_PRIMARY         = 0x00000001,   /* Not used */
> +     LCME_FL_STALE           = 0x00000002,   /* Not used */
> +     LCME_FL_OFFLINE         = 0x00000004,   /* Not used */
> +     LCME_FL_PREFERRED       = 0x00000008,   /* Not used */
> +     LCME_FL_INIT            = 0x00000010,   /* instantiated */
> +};
> +
> +#define LCME_KNOWN_FLAGS     LCME_FL_INIT

What is a "KNOWN" flags?  What isn't known about the other ones?

> +
> +/* lcme_id can be specified as certain flags, and the the first
                                                     ^^^^^^^
Too many "the"s.

> + * bit of lcme_id is used to indicate that the ID is representing
> + * certain LCME_FL_* but not a real ID. Which implies we can have
> + * at most 31 flags (see LCME_FL_XXX).
> + */
> +enum lcme_id {
> +     LCME_ID_INVAL   = 0x0,
> +     LCME_ID_MAX     = 0x7FFFFFFF,
> +     LCME_ID_ALL     = 0xFFFFFFFF,
> +     LCME_ID_NONE    = 0x80000000
> +};
> +
> +#define LCME_ID_MASK LCME_ID_MAX

Why is MASK a #define, but MAX an enum ??

> +
> +struct lov_comp_md_entry_v1 {
> +     __u32                   lcme_id;        /* unique id of component */
> +     __u32                   lcme_flags;     /* LCME_FL_XXX */
> +     struct lu_extent        lcme_extent;    /* file extent for component */
> +     __u32                   lcme_offset;    /* offset of component blob,
> +                                              * start from lov_comp_md_v1
> +                                              */
> +     __u32                   lcme_size;      /* size of component blob */
> +     __u64                   lcme_padding[2];
> +} __packed;
> +
> +enum lov_comp_md_flags;

This enum is empty, and never used.

It eventually gets some LCM_FL_* names added... maybe it should wait
until those are added??

Thanks,
NeilBrown
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20181218/09b52b51/attachment.html>