From: Dave Chinner <david@fromorbit.com>
To: Todd Gill <tgill@redhat.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: file write that exceeds thin device capacity
Date: Wed, 14 Nov 2018 09:10:04 +1100 [thread overview]
Message-ID: <20181113221004.GT19305@dastard> (raw)
In-Reply-To: <18125274-1c2e-6171-a597-4e2ffb165162@redhat.com>
On Tue, Nov 13, 2018 at 02:57:18PM -0500, Todd Gill wrote:
> Hi,
>
> This script creates a 1 TB thin device (device mapper) backed by 1 GB
> of physical space. The script then writes more than 1 GB via
> $BLOCK_SIZE files to XFS. I'm testing to see if recovery can be
> automated.
>
> https://paste.fedoraproject.org/paste/ropelNyOQWCjk3hfK0jltA
>
> When the $BLOCK_SIZE passed to dd is 4k - dd gets an error on the file
> write that exceeds the physical capacity that backs the thin device.
> XFS doesn't indicate any problems.
user data write error.
> If I set the $BLOCK_SIZE to 32k - I see entries in the system log that
> indicate XFS loops retrying the writes.
>
> Is that expected? Is it just more likely to happen with larger block
> sizes?
>
> I’m looking to understand how to recover when a thin device runs out of
> space under XFS.
>
> Example system log entries:
>
> [ +5.048997] XFS (dm-3): metadata I/O error: block 0xf0000
> ("xfs_buf_iodone_callback_error") error 28 numblks 32
> [ +1.376913] XFS: Failing async write: 1164 callbacks suppressed
> [ +0.000004] XFS (dm-3): Failing async write on buffer block 0xf0020.
> Retrying async write.
Filesystem Metadata write error. XFS is configured to retry them by
default. Failing this write will shut down the filesystem as it is a
corruption vector.
If you expand your thin device at this point, the
write will then succeed and the filesystem will continue to operate
normally.
If you configure your filesystem (through
/sys/fs/xfs/<dev>/error/...) to fail metadata writes on ENOSPC
errors, then it will shutdown the filesystem rather than wait for
the thinp device to be expanded.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2018-11-14 8:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-13 19:57 file write that exceeds thin device capacity Todd Gill
2018-11-13 22:10 ` Dave Chinner [this message]
2018-11-15 22:22 ` Eric Sandeen
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=20181113221004.GT19305@dastard \
--to=david@fromorbit.com \
--cc=linux-xfs@vger.kernel.org \
--cc=tgill@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.