All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Brian Foster <bfoster@redhat.com>,
	linux-kernel@vger.kernel.org, xfs@oss.sgi.com,
	Jeff Moyer <jmoyer@redhat.com>,
	linux-fsdevel@vger.kernel.org,
	Ross Zwisler <ross.zwisler@linux.intel.com>
Subject: Re: xfstest failure with xfs, dax and v4.4-rc3
Date: Thu, 3 Dec 2015 09:43:42 -0700	[thread overview]
Message-ID: <20151203164342.GA14849@linux.intel.com> (raw)
In-Reply-To: <20151203065127.GB26718@dastard>

On Thu, Dec 03, 2015 at 05:51:27PM +1100, Dave Chinner wrote:
> As it is, that test does not fail on my DAX testing on RAM disks.
> ISTR it failing up until recently, though. Yeah:
> 
> Last login: Tue Nov 17 08:45:55 2015 from 192.168.1.103
> $ cd ~/src/xfstests-dev; sudo mkfs.xfs -f /dev/ram0 ; sudo xfs_admin -U generate /dev/ram0 ; sudo MOUNT_OPTIONS="-o dax" ./check -g auto
> SECTION       -- xfs
> FSTYP         -- xfs (debug)
> PLATFORM      -- Linux/x86_64 test4 4.3.0-dgc+
> MKFS_OPTIONS  -- -f -bsize=4096 /dev/ram1
> MOUNT_OPTIONS -- -o dax /dev/ram1 /mnt/scratch
> ....
> generic/083 2s ... 1s
> _check_xfs_filesystem: filesystem on /dev/ram1 is inconsistent (c) (see /home/dave/src/xfstests-dev/results//xfs/generic/083.full)
> _check_xfs_filesystem: filesystem on /dev/ram1 is inconsistent (r) (see /home/dave/src/xfstests-dev/results//xfs/generic/083.full)
> ....
> 
> But as I ran earlier today when testing the ENOSPC fix:
> 
> PLATFORM      -- Linux/x86_64 test4 4.4.0-rc2-dgc+
> MKFS_OPTIONS  -- -f -bsize=4096 /dev/ram1
> MOUNT_OPTIONS -- -o dax /dev/ram1 /mnt/scratch
> ....
> generic/083 1s ... 2s
> ....
> 
> So I'm seeing that the current 4.4-rc2 + my local dev tree patches
> appear to have fixed whatever was causing generic/083 to fail
> here...

Yea, interesting, the patch you sent out yesterday:

xfs: Don't use reserved blocks for data blocks with DAX

Makes this issue disappear in my system as well.  Testing with v4.4-rc3
generic/083 fails 50% of the time or so in my setup, but with just that patch
added to v4.4-rc3 I can't make it fail.

> What version of xfsprogs are you using, Ross?

I'm currently using xfsprogs v4.3.0, but the failure occurred when I was using
v4.2.0 as well.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

WARNING: multiple messages have this Message-ID (diff)
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Jeff Moyer <jmoyer@redhat.com>,
	Ross Zwisler <ross.zwisler@linux.intel.com>,
	xfs@oss.sgi.com, Brian Foster <bfoster@redhat.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: xfstest failure with xfs, dax and v4.4-rc3
Date: Thu, 3 Dec 2015 09:43:42 -0700	[thread overview]
Message-ID: <20151203164342.GA14849@linux.intel.com> (raw)
In-Reply-To: <20151203065127.GB26718@dastard>

On Thu, Dec 03, 2015 at 05:51:27PM +1100, Dave Chinner wrote:
> As it is, that test does not fail on my DAX testing on RAM disks.
> ISTR it failing up until recently, though. Yeah:
> 
> Last login: Tue Nov 17 08:45:55 2015 from 192.168.1.103
> $ cd ~/src/xfstests-dev; sudo mkfs.xfs -f /dev/ram0 ; sudo xfs_admin -U generate /dev/ram0 ; sudo MOUNT_OPTIONS="-o dax" ./check -g auto
> SECTION       -- xfs
> FSTYP         -- xfs (debug)
> PLATFORM      -- Linux/x86_64 test4 4.3.0-dgc+
> MKFS_OPTIONS  -- -f -bsize=4096 /dev/ram1
> MOUNT_OPTIONS -- -o dax /dev/ram1 /mnt/scratch
> ....
> generic/083 2s ... 1s
> _check_xfs_filesystem: filesystem on /dev/ram1 is inconsistent (c) (see /home/dave/src/xfstests-dev/results//xfs/generic/083.full)
> _check_xfs_filesystem: filesystem on /dev/ram1 is inconsistent (r) (see /home/dave/src/xfstests-dev/results//xfs/generic/083.full)
> ....
> 
> But as I ran earlier today when testing the ENOSPC fix:
> 
> PLATFORM      -- Linux/x86_64 test4 4.4.0-rc2-dgc+
> MKFS_OPTIONS  -- -f -bsize=4096 /dev/ram1
> MOUNT_OPTIONS -- -o dax /dev/ram1 /mnt/scratch
> ....
> generic/083 1s ... 2s
> ....
> 
> So I'm seeing that the current 4.4-rc2 + my local dev tree patches
> appear to have fixed whatever was causing generic/083 to fail
> here...

Yea, interesting, the patch you sent out yesterday:

xfs: Don't use reserved blocks for data blocks with DAX

Makes this issue disappear in my system as well.  Testing with v4.4-rc3
generic/083 fails 50% of the time or so in my setup, but with just that patch
added to v4.4-rc3 I can't make it fail.

> What version of xfsprogs are you using, Ross?

I'm currently using xfsprogs v4.3.0, but the failure occurred when I was using
v4.2.0 as well.

  reply	other threads:[~2015-12-03 16:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-01 22:43 xfstest failure with xfs, dax and v4.4-rc3 Ross Zwisler
2015-12-01 22:43 ` Ross Zwisler
2015-12-01 23:51 ` Dave Chinner
2015-12-01 23:51   ` Dave Chinner
2015-12-02 15:12   ` Jeff Moyer
2015-12-02 15:12     ` Jeff Moyer
2015-12-03  6:51     ` Dave Chinner
2015-12-03  6:51       ` Dave Chinner
2015-12-03 16:43       ` Ross Zwisler [this message]
2015-12-03 16:43         ` Ross Zwisler

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=20151203164342.GA14849@linux.intel.com \
    --to=ross.zwisler@linux.intel.com \
    --cc=bfoster@redhat.com \
    --cc=david@fromorbit.com \
    --cc=jmoyer@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xfs@oss.sgi.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.