From: Dave Chinner <david@fromorbit.com>
To: "hch@lst.de" <hch@lst.de>
Cc: "Verma, Vishal L" <vishal.l.verma@intel.com>,
"linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
"Williams, Dan J" <dan.j.williams@intel.com>,
"darrick.wong@oracle.com" <darrick.wong@oracle.com>
Subject: Re: 5.3-rc1 regression with XFS log recovery
Date: Mon, 19 Aug 2019 14:15:46 +1000 [thread overview]
Message-ID: <20190819041546.GY6129@dread.disaster.area> (raw)
In-Reply-To: <20190819034948.GA14261@lst.de>
On Mon, Aug 19, 2019 at 05:49:48AM +0200, hch@lst.de wrote:
> On Mon, Aug 19, 2019 at 10:08:31AM +1000, Dave Chinner wrote:
> > > So I can also reproduce the same issue with the ramdisk driver, but not
> > > with any other 4k sector size device (nvmet, scsi target, scsi_debug,
> > > loop).
> >
> > How did you reproduce it? I tried with indentical pmem config to
> > what Vishal was using and couldn't hit it...
>
> Just mkfs and mount the pmem device.
Ran that in a loop overnight, no failures.
> The fake pmem was create by the following kernel command line sniplet:
> "memmap=2000M!1024M,2000M!4096M" and my kernel config is attached. I
Very similar to what I'm using, just 2x8GB pmem instead of the
smaller 1/4GB pair you are using. I even tried manually making it
smaller w/ -d size= and changing log sizes, etc. I tried squeezing
down memory to only 256MB unused (via mlock) but that didn't seem to
change anything, either...
> suspect you'll need CONFIG_SLUB to create the woes, but let me confirm
> that..
Yup, that's what I have configured in my kernel, too.
It's still a mystery to me why I'm not able to reproduce it
easily. If it was just pmem, then I should have found it back when I
tripped over the chaining bug, because the two VMs I were running
testing on at the time were an iscsi test rig and an pmem test rig.
The iscsi one tripped over the chaining bug, the pmem one has had no
problems....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2019-08-19 4:16 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-16 20:59 5.3-rc1 regression with XFS log recovery Verma, Vishal L
2019-08-18 7:11 ` hch
2019-08-18 7:41 ` hch
2019-08-18 17:34 ` hch
2019-08-19 0:08 ` Dave Chinner
2019-08-19 3:49 ` hch
2019-08-19 4:11 ` hch
2019-08-19 4:22 ` Dave Chinner
2019-08-19 4:29 ` hch
2019-08-19 4:40 ` hch
2019-08-19 5:31 ` Dave Chinner
2019-08-20 6:14 ` hch
2019-08-20 4:41 ` Dave Chinner
2019-08-20 5:53 ` hch
2019-08-20 7:44 ` Dave Chinner
2019-08-20 8:13 ` Ming Lei
2019-08-20 9:24 ` Ming Lei
2019-08-20 16:30 ` Verma, Vishal L
2019-08-20 21:44 ` Dave Chinner
2019-08-20 22:08 ` Verma, Vishal L
2019-08-20 23:53 ` Dave Chinner
2019-08-21 2:19 ` Ming Lei
2019-08-21 1:56 ` Ming Lei
2019-08-19 4:15 ` Dave Chinner [this message]
2019-08-19 17:19 ` Verma, Vishal L
2019-08-21 0:26 ` Dave Chinner
2019-08-21 0:44 ` hch
2019-08-21 1:08 ` Dave Chinner
2019-08-21 1:56 ` Verma, Vishal L
2019-08-21 6:15 ` Dave Chinner
2019-08-26 17:32 ` Verma, Vishal L
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=20190819041546.GY6129@dread.disaster.area \
--to=david@fromorbit.com \
--cc=dan.j.williams@intel.com \
--cc=darrick.wong@oracle.com \
--cc=hch@lst.de \
--cc=linux-xfs@vger.kernel.org \
--cc=vishal.l.verma@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox