On Wed, Aug 3, 2016 at 4:16 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > On Wed, Aug 03, 2016 at 04:37:13PM -0600, Ross Zwisler wrote: >> On Wed, Aug 03, 2016 at 11:11:27AM -0600, Ross Zwisler wrote: >> > On Wed, Aug 03, 2016 at 10:33:54AM +1000, Dave Chinner wrote: >> > > Hi folks, >> > > >> > > Just hit a reproducable hang in generic/361. Essentially this on >> > > a 8GB pmem device: >> > > >> > > mkfs.xfs -f /dev/pmem1 >> > > mount -o dax /dev/pmem1 /mnt/scratch >> > > xfs_io -f -c "truncate 1g" test.img >> > > losetup -f --show /mnt/scratch/test.img >> > > mkfs.xfs -f /dev/loop0 >> > > >> > > And the mkfs.xfs command hangs with a discard that never completes: > .... >> > > This only reproduces when the underlying filesystem is mounted with >> > > -o dax, so there is a bad interaction with loop devices and DAX >> > > occurring somewhere. generic/361 is a recent test (committed june 14) >> > > so this probably hasn't actually been tested until now. >> > > >> > > I haven't got time to look at this right now, hence the report. >> > >> > Cool, thanks for the report. I've reproduced this with linux/master, and the >> > test passes with v4.7. >> > >> > Running a bisect... >> >> This bisected to a commit to the block layer code. I've sent a bug report to >> the author of the commit. > > And the commit id is ...? c2df40dfb8c0 drivers: use req op accessor _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
