From: Dave Chinner <david@fromorbit.com>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Brian Foster <bfoster@redhat.com>,
linux-xfs@vger.kernel.org, Dave Chinner <dchinner@redhat.com>
Subject: Re: attr fork related fstests failures on for-next
Date: Tue, 30 Mar 2021 07:48:28 +1100 [thread overview]
Message-ID: <20210329204828.GP63242@dread.disaster.area> (raw)
In-Reply-To: <20210329183120.GH4090233@magnolia>
On Mon, Mar 29, 2021 at 11:31:20AM -0700, Darrick J. Wong wrote:
> On Mon, Mar 29, 2021 at 02:16:04PM -0400, Brian Foster wrote:
> > Hi,
> >
> > I'm seeing a couple different fstests failures on current for-next that
> > appear to be associated with e6a688c33238 ("xfs: initialise attr fork on
> > inode create"). The first is xfs_check complaining about sb versionnum
> > bits on various tests:
> >
> > generic/003 16s ... _check_xfs_filesystem: filesystem on /dev/mapper/test-scratch is inconsistent (c)
> > (see /root/xfstests-dev/results//generic/003.full for details)
> > # cat results/generic/003.full
> > ...
> > _check_xfs_filesystem: filesystem on /dev/mapper/test-scratch is inconsistent (c)
> > *** xfs_check output ***
> > sb versionnum missing attr bit 10
> > *** end xfs_check output
>
> FWIW I think this because that commit sets up an attr fork without
> setting ATTR and ATTR2 in sb_version like xfs_bmap_add_attrfork does...
Maybe, but mkfs.xfs sets ATTR2 by default and has for a long time.
I'm not seeing this fail on either v4 or v5 filesystems on for-next
with a current xfsprogs (5.11.0), so what environment is this test
failing in?
SECTION -- xfs
FSTYP -- xfs (debug)
PLATFORM -- Linux/x86_64 test3 5.12.0-rc5-dgc+ #3074 SMP
PREEMPT Tue Mar 30 07:37:47 AEDT 2021
MKFS_OPTIONS -- -f -m rmapbt=1,reflink=1 -i sparse=1 /dev/pmem1
MOUNT_OPTIONS -- /dev/pmem1 /mnt/scratch
generic/003 11s ... 11s
Passed all 1 tests
Xunit report: /home/dave/src/xfstests-dev/results//xfs/result.xml
SECTION -- xfs_v4
FSTYP -- xfs (debug)
PLATFORM -- Linux/x86_64 test3 5.12.0-rc5-dgc+ #3074 SMP
PREEMPT Tue Mar 30 07:37:47 AEDT 2021
MKFS_OPTIONS -- -f -m crc=0 /dev/pmem1
MOUNT_OPTIONS -- /dev/pmem1 /mnt/scratch
generic/003 11s ... 11s
Passed all 1 tests
> > With xfs_check bypassed, repair eventually complains about some attr
> > forks. The first point I hit this variant is generic/117:
> >
> > generic/117 9s ... _check_xfs_filesystem: filesystem on /dev/mapper/test-scratch is inconsistent (r)
> > (see /root/xfstests-dev/results//generic/117.full for details)
> > # cat results//generic/117.full
> > ...
> > _check_xfs_filesystem: filesystem on /dev/mapper/test-scratch is inconsistent (r)
> > *** xfs_repair -n output ***
> > ...
> > Phase 3 - for each AG...
> > - scan (but don't clear) agi unlinked lists...
> > - process known inodes and perform inode discovery...
> > - agno = 0
> > bad attr fork offset 24 in dev inode 135, should be 1
> > would have cleared inode 135
> > bad attr fork offset 24 in dev inode 142, should be 1
> > would have cleared inode 142
>
> ...and I think this is because xfs_default_attroffset doesn't set the
> correct value for device files. For those kinds of files, xfs_repair
> requires the data fork to be exactly 8 bytes.
Again, doesn't fail with xfsprogs 5.11.0 here for either v4 or v5
filesystems...
SECTION -- xfs
FSTYP -- xfs (debug)
PLATFORM -- Linux/x86_64 test3 5.12.0-rc5-dgc+ #3074 SMP
PREEMPT Tue Mar 30 07:37:47 AEDT 2021
MKFS_OPTIONS -- -f -m rmapbt=1,reflink=1 -i sparse=1 /dev/pmem1
MOUNT_OPTIONS -- /dev/pmem1 /mnt/scratch
generic/117 1s ... 2s
Passed all 1 tests
Xunit report: /home/dave/src/xfstests-dev/results//xfs/result.xml
SECTION -- xfs_v4
FSTYP -- xfs (debug)
PLATFORM -- Linux/x86_64 test3 5.12.0-rc5-dgc+ #3074 SMP
PREEMPT Tue Mar 30 07:37:47 AEDT 2021
MKFS_OPTIONS -- -f -m crc=0 /dev/pmem1
MOUNT_OPTIONS -- /dev/pmem1 /mnt/scratch
generic/117 2s ... 2s
Passed all 1 tests
I'm going to need more information on what environment these
failures are being generated in.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2021-03-29 20:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-29 18:16 attr fork related fstests failures on for-next Brian Foster
2021-03-29 18:31 ` Darrick J. Wong
2021-03-29 20:48 ` Dave Chinner [this message]
2021-03-29 21:06 ` Dave Chinner
2021-03-29 21:07 ` Darrick J. Wong
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=20210329204828.GP63242@dread.disaster.area \
--to=david@fromorbit.com \
--cc=bfoster@redhat.com \
--cc=dchinner@redhat.com \
--cc=djwong@kernel.org \
--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 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.