Re: [PATCH 02/17] Set up infastructure for deferred attribute operations

[Dave Chinner <david@fromorbit.com>]

On Mon, Oct 09, 2017 at 03:51:42PM -0700, Allison Henderson wrote:
> On 10/09/2017 02:25 PM, Allison Henderson wrote:
> >On 10/8/2017 9:20 PM, Dave Chinner wrote:
> >>On Fri, Oct 06, 2017 at 03:05:33PM -0700, Allison Henderson wrote:
> >>>Signed-off-by: Allison Henderson <allison.henderson@oracle.com>
> >>>    /*
> >>>   * Inode Log Item Format definitions.
> >>>@@ -863,4 +872,45 @@ struct xfs_icreate_log {
> >>>      __be32        icl_gen;    /* inode generation number to use */
> >>>  };
> >>>  +/* Flags for defered attribute operations */
> >>>+#define ATTR_OP_FLAGS_SET    0x01    /* Set the attribute */
> >>>+#define ATTR_OP_FLAGS_REMOVE    0x02    /* Remove the attribute */
> >>>+#define ATTR_OP_FLAGS_MAX    0x02    /* Max flags */
> >>>+
> >>>+/*
> >>>+ * ATTRI/ATTRD log format definitions
> >>>+ */
> >>>+struct xfs_attr {
> >>>+    xfs_ino_t    attr_ino;
> >>>+    uint32_t    attr_op_flags;
> >>>+    uint32_t    attr_nameval_len;
> >>>+    uint32_t    attr_name_len;
> >>>+    uint32_t        attr_flags;
> >>>+    uint8_t        attr_nameval[MAX_NAMEVAL_LEN];
> >>>+};
> >>
> >>"struct xfs_attr" is very generic. This ends up in the log on disk,
> >>right? So it's a log format structure? struct xfs_attr_log_format?
> >>
> >>This also needs padding to ensure it's size is 64bit aligned.
> >>
> Hmm, if this structure is meant to be stored on disk, is it really a
> good idea to put pointers in here as you mentioned in your
> conclusion below?  If we get remounted or rebooted and loose the
> pointer that may not work.  Or am I not understanding what you
> meant?

The log format structure on disk needs to be encoded correctly - it
will contain data, not pointers. The in-memory log item will contain
the pointers to the xattr name/value buffers. i.e.

struct xfs_attr_log_item {
	struct xfs_log_item	item;
	....
	int			namelen;
	void			*name_buf;
	int			valuelen;
	void			*value_buf;
	struct xfs_attr_log_format alf;
};

And the log format structure looks like:

struct xfs_attr_log_format {
	be64		ino;
	be32		gen;
	be32		intent_id;
	be32		op_flags;
	be32		attr_flags;
	be32		namelen;
	be32		valuelen;
	/* name gets copied here into first trailing log iovec */
	/* value gets copied here into second trailing log iovec */
};

note that the intent id is used by recovery to make the intent item
to the done item - that's probably what the "id" variable in the
original structure you had was supposed to be used for. :P

So essentially the ->item_size code does:

	/* log format header */
	nvecs++;
	nbytes += sizeof(struct xfs_attr_log_format);
	if (opflags == remove ||
	    opflags == flipflags)
		return;

	/* add/set */
	nvecs += 2;
	nbytes += namelen;
	nbytes += valuelen;
	return;

And the ->item_format code does something like:

	xlog_copy_iovec(lv, &vecp, XLOG_REG_TYPE_ATTR_FORMAT,
	                &alip->alf, sizeof(struct xfs_attr_log_format));

	if (opflags == remove ||
	    opflags == flipflags)
		return;

	xlog_copy_iovec(lv, &vecp, XLOG_REG_TYPE_ATTR_NAME,
	                alip->name_buf, alip->namelen);
	xlog_copy_iovec(lv, &vecp, XLOG_REG_TYPE_ATTR_VALUE,
	                alip->value_buf, alip->valuelen);

Make a bit more sense now?

I suspect taht because we won't ever relog a "set" intent, we can
clear the name_buf/value_buf pointers from the log item once we've
copied them into the log vector. That means we can use pointers to
the buffers containing the name and value already allocated in the
attr code and so won't need to allocate another set of buffers just
for the log item.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com