linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@dilger.ca>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH -v2 2/2] ext4: simulate various I/O and checksum errors when reading metadata
Date: Thu, 5 Dec 2019 12:05:30 -0700	[thread overview]
Message-ID: <8504AF0E-39F8-4C56-86EE-9945E15C1A16@dilger.ca> (raw)
In-Reply-To: <20191204032335.7683-2-tytso@mit.edu>

[-- Attachment #1: Type: text/plain, Size: 1537 bytes --]

On Dec 3, 2019, at 8:23 PM, Theodore Ts'o <tytso@mit.edu> wrote:
> 
> This allows us to test various error handling code paths
> 
> Previous-Version-Link: https://lore.kernel.org/r/20191121183036.29385-2-tytso@mit.edu
> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
> ---
> 
> +/*
> + * Simulate_fail flags
> + */
> +#define EXT4_SIM_BBITMAP_EIO	0x00000001
> +#define EXT4_SIM_BBITMAP_CRC	0x00000002
> +#define EXT4_SIM_IBITMAP_EIO	0x00000004
> +#define EXT4_SIM_IBITMAP_CRC	0x00000008
> +#define EXT4_SIM_INODE_EIO	0x00000010
> +#define EXT4_SIM_INODE_CRC	0x00000020
> +#define EXT4_SIM_DIRBLOCK_EIO	0x00000040
> +#define EXT4_SIM_DIRBLOCK_CRC	0x00000080

Do we really need to have the ability to inject several different failures
at the same time?  This will only allow 32 or 64 different failure hooks.

IMHO it would be much more flexible to have these as an enum of independent
values.  That does somewhat limit the ability to inject multiple failures,
but allows for many more different/specific fault injection points to be
added in the future.  We have hundreds of different fault points in Lustre
to simulate hard-to-hit race conditions and trigger specific error paths.

If this patch has already been landed, it would still be possible to change
ext4_simulate_fail() to check "if (likely(old != flag))" rather than just
the bit.  That allows making this into an enum that just happens to have an
non-consecutive sequence of values assigned rather than a bitmask.


Cheers, Andreas






[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 873 bytes --]

  reply	other threads:[~2019-12-05 19:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-04  3:23 [PATCH -v2 1/2] ext4: save the error code which triggered an ext4_error() in the superblock Theodore Ts'o
2019-12-04  3:23 ` [PATCH -v2 2/2] ext4: simulate various I/O and checksum errors when reading metadata Theodore Ts'o
2019-12-05 19:05   ` Andreas Dilger [this message]
2019-12-09  1:23     ` [PATCH -v3] " Theodore Ts'o
2019-12-09  4:14       ` Andreas Dilger
2019-12-13 18:45         ` Theodore Y. Ts'o
2019-12-13 11:29 ` [PATCH -v2 1/2] ext4: save the error code which triggered an ext4_error() in the superblock Jan Kara
2019-12-13 18:50   ` Theodore Y. Ts'o

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=8504AF0E-39F8-4C56-86EE-9945E15C1A16@dilger.ca \
    --to=adilger@dilger.ca \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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;
as well as URLs for NNTP newsgroup(s).