From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932333AbbHFPdz (ORCPT ); Thu, 6 Aug 2015 11:33:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57373 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755134AbbHFPds (ORCPT ); Thu, 6 Aug 2015 11:33:48 -0400 From: Jeff Moyer To: "Wilcox\, Matthew R" Cc: "linda.knippers\@hp.com" , "linux-kernel\@vger.kernel.org" , "linux-fsdevel\@vger.kernel.org" Subject: Re: regression introduced by "block: Add support for DAX reads/writes to block devices" References: <100D68C7BA14664A8938383216E40DE04091408C@FMSMSX114.amr.corp.intel.com> X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? Date: Thu, 06 Aug 2015 11:33:45 -0400 In-Reply-To: <100D68C7BA14664A8938383216E40DE04091408C@FMSMSX114.amr.corp.intel.com> (Matthew R. Wilcox's message of "Thu, 6 Aug 2015 14:21:24 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org "Wilcox, Matthew R" writes: > I think I see the problem. I'm kind of wrapped up in other things > right now; can you try replacing the line in dax_io(): > > - bh->b_size = PAGE_ALIGN(end - pos); > + bh->b_size = ALIGN(end - pos, 1 << blkbits); That's not gonna work either. :) You'll end up with -EINVAL since bdev_direct_access wants the sector to be aligned to a page: if (sector % (PAGE_SIZE / 512)) return -EINVAL; I think you really want to call direct_access with the full page, and then tease out the part you want up in dax_io, right? I'll take a crack at it if you're busy. Cheers, Jeff > -----Original Message----- > From: Jeff Moyer [mailto:jmoyer@redhat.com] > Sent: Wednesday, August 05, 2015 1:19 PM > To: Wilcox, Matthew R; linda.knippers@hp.com > Cc: linux-kernel@vger.kernel.org; linux-fsdevel@vger.kernel.org > Subject: regression introduced by "block: Add support for DAX reads/writes to block devices" > > Hi, Matthew, > > Linda Knippers noticed that commit (bbab37ddc20b) breaks mkfs.xfs: > > # mkfs -t xfs -f /dev/pmem0 > meta-data=/dev/pmem0 isize=256 agcount=4, agsize=524288 blks > = sectsz=512 attr=2, projid32bit=1 > = crc=0 finobt=0 > data = bsize=4096 blocks=2097152, imaxpct=25 > = sunit=0 swidth=0 blks > naming =version 2 bsize=4096 ascii-ci=0 ftype=0 > log =internal log bsize=4096 blocks=2560, version=2 > = sectsz=512 sunit=0 blks, lazy-count=1 > realtime =none extsz=4096 blocks=0, rtextents=0 > mkfs.xfs: read failed: Numerical result out of range > > I sat down with Linda to look into it, and the problem is that mkfs.xfs > sets the blocksize of the device to 512 (via BLKBSZSET), and then reads > from the last sector of the device. This results in dax_io trying to do > a page-sized I/O at 512 bytes from the end of the device. > bdev_direct_access, receiving this bogus pos/size combo, returns > -ERANGE: > > if ((sector + DIV_ROUND_UP(size, 512)) > > part_nr_sects_read(bdev->bd_part)) > return -ERANGE; > > Given that file systems supporting dax refuse to mount with a blocksize > != page size, I'm guessing this is sort of expected behavior. However, > we really shouldn't be breaking direct I/O on pmem devices. > > So, what do you want to do? We could make the pmem device's logical > block size fixed at the sytem page size. Or, we could modify the dax > code to work with blocksize < pagesize. Or, we could continue using the > direct I/O codepath for direct block device access. What do you think? > > Thaks, > Jeff and Linda