From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-xfs@vger.kernel.org
Subject: Re: delalloc and reflink fixes & tweaks V3
Date: Fri, 5 Oct 2018 19:29:06 +1000 [thread overview]
Message-ID: <20181005092906.GG12041@dastard> (raw)
In-Reply-To: <20181002174207.25275-1-hch@lst.de>
On Tue, Oct 02, 2018 at 10:41:59AM -0700, Christoph Hellwig wrote:
> Hi all,
>
> this series contains the basic reflink and delalloc fixups intended
> for 4.20. All the bits that need more work are left out for now.
>
> Changes since v2:
> - add a new comment
> - drop the patch to use unwritten extents for delalloc by default,
> it didn't actually do what it was intended to do, because there
> was no test to check for that, and actually changing that caused
> a few regressions that need more time looking into
> - add two new unwritten extent related cleanup patches
>
> Changes since v1:
> - drop various patches
> - print the inode number for dangling delalloc extents
Something in this patchset causes generic/127 to corrupt the rmap
btree. 100% failure rate across all my test machines:
[ 878.026760] run fstests generic/127 at 2018-10-05 17:31:13
[ 888.752797] XFS: Assertion failed: fs_is_ok, file: fs/xfs/libxfs/xfs_rmap.c, line: 418
......
[ 888.788156] Call Trace:
[ 888.788683] xfs_rmap_unmap+0x633/0x980
[ 888.789461] ? kmem_zone_alloc+0x61/0xe0
[ 888.790245] xfs_rmap_finish_one+0x2d0/0x340
[ 888.791099] xfs_trans_log_finish_rmap_update+0x2f/0x40
[ 888.792146] xfs_rmap_update_finish_item+0x2c/0x40
[ 888.793093] xfs_defer_finish_noroll+0x184/0x520
[ 888.793996] ? xfs_rmap_update_cancel_item+0x10/0x10
[ 888.794965] ? xfs_free_file_space+0x355/0x390
[ 888.795850] __xfs_trans_commit+0x189/0x370
[ 888.796675] xfs_free_file_space+0x355/0x390
[ 888.797523] xfs_file_fallocate+0x1b3/0x330
[ 888.798356] ? __sb_start_write+0x8d/0xc0
[ 888.799153] vfs_fallocate+0x13d/0x270
[ 888.799908] ksys_fallocate+0x3c/0x70
[ 888.800634] __x64_sys_fallocate+0x1a/0x20
[ 888.801454] do_syscall_64+0x5a/0x180
[ 888.802186] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[
And the corruption is then tripped over again after reboot during
log recovery:
[ 133.805375] XFS (sdb): Mounting V5 Filesystem
[ 134.067122] XFS (sdb): Starting recovery (logdev: internal)
[ 134.228779] XFS: Assertion failed: fs_is_ok, file: fs/xfs/libxfs/xfs_rmap.c, line: 545
.....
[ 134.253087] Call Trace:
[ 134.253630] xfs_rmap_unmap+0x467/0x980
[ 134.254363] ? kmem_zone_alloc+0x61/0xe0
[ 134.255108] xfs_rmap_finish_one+0x2d0/0x340
[ 134.255914] xfs_trans_log_finish_rmap_update+0x2f/0x40
[ 134.256899] xfs_rui_recover+0x211/0x2d0
[ 134.257667] xlog_recover_process_rui+0x3c/0x60
[ 134.258521] ? xfs_trans_ail_cursor_first+0x17/0x80
[ 134.259427] xlog_recover_process_intents+0x283/0x310
[ 134.260374] ? xfs_iget+0x514/0xad0
[ 134.261033] ? xlog_recover_finish+0x18/0xa0
[ 134.261864] xlog_recover_finish+0x18/0xa0
[ 134.262640] xfs_log_mount_finish+0x6f/0x110
[ 134.263430] xfs_mountfs+0x66f/0x8e0
[ 134.264096] ? xfs_mru_cache_create+0x15a/0x1b0
[ 134.264937] xfs_fs_fill_super+0x4a5/0x650
[ 134.265737] ? xfs_test_remount_options+0x60/0x60
[ 134.266625] mount_bdev+0x174/0x1b0
[ 134.267288] mount_fs+0x30/0x150
[ 134.267856] vfs_kern_mount.part.30+0x54/0x120
[ 134.268686] do_mount+0x5dd/0xc90
[ 134.269344] ? memdup_user+0x3e/0x70
[ 134.270491] ksys_mount+0x80/0xd0
[ 134.271555] __x64_sys_mount+0x21/0x30
[ 134.272739] do_syscall_64+0x5a/0x180
[ 134.273459] entry_SYSCALL_64_after_hwframe+0x49/0xbe
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
prev parent reply other threads:[~2018-10-05 16:27 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-02 17:41 delalloc and reflink fixes & tweaks V3 Christoph Hellwig
2018-10-02 17:42 ` [PATCH 1/8] xfs: remove XFS_IO_INVALID Christoph Hellwig
2018-10-02 17:42 ` [PATCH 2/8] xfs: remove suport for filesystems without unwritten extent flag Christoph Hellwig
2018-10-03 12:15 ` Brian Foster
2018-10-03 14:52 ` Darrick J. Wong
2018-10-03 14:54 ` Christoph Hellwig
2018-10-02 17:42 ` [PATCH 3/8] xfs: remove magic handling of unwritten extents in xfs_bmapi_allocate Christoph Hellwig
2018-10-03 12:15 ` Brian Foster
2018-10-06 9:34 ` Dave Chinner
2018-10-06 9:43 ` Christoph Hellwig
2018-10-07 10:13 ` Christoph Hellwig
2018-10-07 22:02 ` Dave Chinner
2018-10-08 2:24 ` Dave Chinner
2018-10-08 6:07 ` Dave Chinner
2018-10-02 17:42 ` [PATCH 4/8] xfs: handle zeroing in xfs_file_iomap_begin_delay Christoph Hellwig
2018-10-03 12:16 ` Brian Foster
2018-10-02 17:42 ` [PATCH 5/8] xfs: remove the unused shared argument to xfs_reflink_reserve_cow Christoph Hellwig
2018-10-02 17:42 ` [PATCH 6/8] xfs: remove the unused trimmed argument from xfs_reflink_trim_around_shared Christoph Hellwig
2018-10-02 17:42 ` [PATCH 7/8] xfs: fix fork selection in xfs_find_trim_cow_extent Christoph Hellwig
2018-10-02 17:42 ` [PATCH 8/8] xfs: print dangling delalloc extents Christoph Hellwig
2018-10-05 9:29 ` Dave Chinner [this message]
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=20181005092906.GG12041@dastard \
--to=david@fromorbit.com \
--cc=hch@lst.de \
--cc=linux-xfs@vger.kernel.org \
/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).