linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Catherine Hoang <catherine.hoang@oracle.com>
Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org
Subject: Re: [PATCH v2 1/1] xfstests: Add Log Attribute Replay test
Date: Thu, 2 Sep 2021 09:36:47 +1000	[thread overview]
Message-ID: <20210901233647.GC1756565@dread.disaster.area> (raw)
In-Reply-To: <20210901221006.125888-2-catherine.hoang@oracle.com>

On Wed, Sep 01, 2021 at 10:10:06PM +0000, Catherine Hoang wrote:
> From: Allison Henderson <allison.henderson@oracle.com>
> 
> This patch adds a test to exercise the log attribute error
> inject and log replay.  Attributes are added in increaseing
> sizes up to 64k, and the error inject is used to replay them
> from the log
> 
> Signed-off-by: Allison Henderson <allison.henderson@oracle.com>
> Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
> ---
> V2: Updated attr sizes
>    Added attr16k test
>    Removed rm -f $seqres.full
>    Added filtering for SCRATCH_MNT
....
> +_test_attr_replay()
> +{
> +	attr_name=$1
> +	attr_value=$2
> +	touch $testfile.1
> +
> +	echo "Inject error"
> +	_scratch_inject_error "larp"
> +
> +	echo "Set attribute"
> +	echo "$attr_value" | ${ATTR_PROG} -s "$attr_name" $testfile.1 2>&1 | \
> +			    _filter_scratch
> +
> +	echo "FS should be shut down, touch will fail"
> +	touch $testfile.1 2>&1 | _filter_scratch
> +
> +	echo "Remount to replay log"
> +	_scratch_inject_logprint >> $seqres.full

Huh. That function name has nothing to do with remount or dumping
the log. _scratch_remount_dump_log() would at least describe what it
does (indeed, it is just scratch_unmount; scratch_dump_log;
scratch_mount). Can you follow this up with another patch to
rename _scratch_inject_logprint() to _scratch_remount_dump_log()
and also do the same for the equivalent _test_inject_logprint()
function? They should probably move to common/xfs from
common/inject, too...

> +
> +	echo "FS should be online, touch should succeed"
> +	touch $testfile.1
> +
> +	echo "Verify attr recovery"
> +	_getfattr --absolute-names $testfile.1 | _filter_scratch
> +	$ATTR_PROG -g $attr_name $testfile.1 | md5sum
> +
> +	echo ""
> +}

Ok, so this tests just the "set" operation.

FWIW, there is no need to echo test beahviour descriptions to the
output file. Each of the "echo" statements here should just be
comments.

> +
> +
> +# real QA test starts here
> +_supported_fs xfs
> +
> +_require_scratch
> +_require_attrs
> +_require_xfs_io_error_injection "larp"
> +_require_xfs_sysfs debug/larp
> +
> +# turn on log attributes
> +echo 1 > /sys/fs/xfs/debug/larp
> +
> +_scratch_unmount >/dev/null 2>&1
> +
> +#attributes of increaseing sizes
> +attr16="0123456789ABCDEF"
> +attr64="$attr16$attr16$attr16$attr16"
> +attr256="$attr64$attr64$attr64$attr64"
> +attr1k="$attr256$attr256$attr256$attr256"
> +attr4k="$attr1k$attr1k$attr1k$attr1k"
> +attr8k="$attr4k$attr4k"
> +attr16k="$attr8k$attr8k"
> +attr32k="$attr16k$attr16k"
> +attr64k="$attr32k$attr32k"
> +
> +echo "*** mkfs"
> +_scratch_mkfs_xfs >/dev/null
> +
> +echo "*** mount FS"
> +_scratch_mount
> +
> +testfile=$SCRATCH_MNT/testfile
> +echo "*** make test file 1"
> +
> +_test_attr_replay "attr_name1" $attr16
> +_test_attr_replay "attr_name2" $attr64
> +_test_attr_replay "attr_name3" $attr256
> +_test_attr_replay "attr_name4" $attr1k
> +_test_attr_replay "attr_name5" $attr4k
> +_test_attr_replay "attr_name6" $attr8k
> +_test_attr_replay "attr_name7" $attr16k
> +_test_attr_replay "attr_name8" $attr32k
> +_test_attr_replay "attr_name9" $attr64k

Hmmm - all attributes have different names, so this only tests
the "create new attribute" operation, not the "replace attribute"
or "remove attribute" operations. 

Also, why were the given sizes chosen? It seems to me like we should
be selecting the attribute sizes based on the different operations
they trigger.

For an empty 512 byte inode on 4kB block size fs, we have ~300 bytes
available for local attr storage. Hence both attr16 and attr64 will
be stored inline.  attr256 will trigger sf-to-leaf transition with
existing entries.  attr1k will do a leaf internal addition. attr4k
will be stored externally as a remote attr, as will all the
remaining larger attrs.

Hence this doesn't test the following cases:
- empty to leaf transition on first attr insert
- remote xattr insertion when empty
- leaf split/addition due to filling a leaf block
- extent format to btree format transistion (i.e. tree level
  increase)

IOWs, for a 512 byte inode and 4kB block size fs, the tests really
need to be:

- empty, add inline attr	(64 bytes)
- empty, add internal attr	(1kB)
- empty, add remote attr	(64kB)
- inline, add inline attr	(64 bytes)
- inline, add internal attr	(1kB)
- inline, add remote attr	(64kB)
- extent, add internal attr	(1kB)
- extent, add multiple internal attr (inject error on split operation)
- extent, add multiple internal attr (inject error on fork
				  transition to btree format operation)
- extent, add remote attr	(64kB)
- btree, add multiple internal	(1kB)
- btree, add remote attr	(64kB)

This covers all the different attr fork storage forms and
transitions between the different forms.

We then need to cover the same cases but in reverse for attr removal
(e.g. recovery of leaf merge operations, btree to extent form
conversion, etc).

We also need to have coverage of attr overwrite recovery of all the
attr formats (shortform, leaf internal and remote) because these
both add and remove attributes of the same name. We probably want
different points of error injection for these so that we can force
it to recover from different points in the replace operation...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2021-09-01 23:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-01 22:10 [PATCH v2 0/1] Log Attribute Replay Test Catherine Hoang
2021-09-01 22:10 ` [PATCH v2 1/1] xfstests: Add Log Attribute Replay test Catherine Hoang
2021-09-01 23:36   ` Dave Chinner [this message]
2021-09-02  8:58     ` Allison Henderson

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=20210901233647.GC1756565@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=catherine.hoang@oracle.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --subject='Re: [PATCH v2 1/1] xfstests: Add Log Attribute Replay test' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).