lkml.org 
[lkml]   [2022]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4] btrfs: add fs state details to error messages.
On Wed, Feb 23, 2022 at 02:38:06PM -0500, Sweet Tea Dorminy wrote:
> When a filesystem goes read-only due to an error, multiple errors tend
> to be reported, some of which are knock-on failures. Logging fs_states,
> in btrfs_handle_fs_error() and btrfs_printk() helps distinguish the
> first error from subsequent messages which may only exist due to an
> error state.
>
> Under the new format, most initial errors will look like:
> `BTRFS: error (device loop0) in ...`
> while subsequent errors will begin with:
> `error (device loop0: state E) in ...`
>
> An initial transaction abort error will look like
> `error (device loop0: state A) in ...`
> and subsequent messages will contain
> `(device loop0: state EA) in ...`
>
> Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>

Added to misc-next with some minor updates, thanks.

> ---
> v4:
> - Adjusted state translation table to contain chars instead of
> strings.
>
> v3:
> - Reworked btrfs_state_to_string to use an array mapping all states
> to various error chars, or nothing, explicitly. Added error logging
> for more states, as requested.
> - Consolidated buffer length definition
> - ttps://lore.kernel.org/linux-btrfs/8a2a73ab4b48a4e73d24cf7f10cc0fe245d50a84.1645562216.git.sweettea-kernel@dorminy.me/
>
> v2:
> - Changed btrfs_state_to_string() for clarity
> - Removed superfluous whitespace change
> - https://lore.kernel.org/linux-btrfs/084c136c6bb2d20ca0e91af7ded48306d52bb910.1645210326.git.sweettea-kernel@dorminy.me/
>
> v1:
> - https://lore.kernel.org/linux-btrfs/20220212191042.94954-1-sweettea-kernel@dorminy.me/
>
> fs/btrfs/ctree.h | 2 ++
> fs/btrfs/super.c | 62 +++++++++++++++++++++++++++++++++++++++++-------
> 2 files changed, 56 insertions(+), 8 deletions(-)
>
> diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
> index 8992e0096163..3db337cd015a 100644
> --- a/fs/btrfs/ctree.h
> +++ b/fs/btrfs/ctree.h
> @@ -148,6 +148,8 @@ enum {
>
> /* Indicates there was an error cleaning up a log tree. */
> BTRFS_FS_STATE_LOG_CLEANUP_ERROR,
> +
> + BTRFS_FS_STATE_COUNT,
> };
>
> #define BTRFS_BACKREF_REV_MAX 256
> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
> index 4d947ba32da9..7ef6a3e494d0 100644
> --- a/fs/btrfs/super.c
> +++ b/fs/btrfs/super.c
> @@ -66,6 +66,46 @@ static struct file_system_type btrfs_root_fs_type;
>
> static int btrfs_remount(struct super_block *sb, int *flags, char *data);
>
> +#define STATE_STRING_PREFACE ": state "
> +#define STATE_STRING_BUF_LEN \
> + (sizeof(STATE_STRING_PREFACE) + BTRFS_FS_STATE_COUNT)
> +
> +/* Characters to print to indicate error conditions. RO is not an error. */
> +static const char fs_state_chars[] = {
> + [BTRFS_FS_STATE_ERROR] = 'E',
> + [BTRFS_FS_STATE_REMOUNTING] = 'M',
> + [BTRFS_FS_STATE_RO] = 0,
> + [BTRFS_FS_STATE_TRANS_ABORTED] = 'A',
> + [BTRFS_FS_STATE_DEV_REPLACING] = 'P',
> + [BTRFS_FS_STATE_DUMMY_FS_INFO] = 0,
> + [BTRFS_FS_STATE_NO_CSUMS] = 0,

I've added 'C' for this, as it's an interesting state (data checksums
not verified) and renamed the device replace to 'R'.

> + [BTRFS_FS_STATE_LOG_CLEANUP_ERROR] = 'L',
> +};
> +
> +static void btrfs_state_to_string(const struct btrfs_fs_info *info, char *buf)
> +{
> + unsigned int bit;
> + unsigned int states_printed = 0;

This could be a simple bool indicator.

> + char *curr = buf;
> +
> + memcpy(curr, STATE_STRING_PREFACE, sizeof(STATE_STRING_PREFACE));
> + curr += sizeof(STATE_STRING_PREFACE) - 1;
> +
> + for_each_set_bit(bit, &info->fs_state, sizeof(info->fs_state)) {
> + WARN_ON_ONCE(bit >= BTRFS_FS_STATE_COUNT);
> + if ((bit < BTRFS_FS_STATE_COUNT) && fs_state_chars[bit]) {
> + *curr++ = fs_state_chars[bit];
> + states_printed++;
> + }
> + }
> +
> + /* If no states were printed, reset the buffer */
> + if (!states_printed)
> + curr = buf;
> +
> + *curr++ = '\0';
> +}

\
 
 \ /
  Last update: 2022-02-24 14:26    [W:0.358 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site