On 8/10/2015 5:27 PM, Dave Chinner wrote: > On Mon, Aug 10, 2015 at 12:32:08PM -0400, Linda Knippers wrote: >> On 8/9/2015 4:52 AM, Boaz Harrosh wrote: >>> On 08/06/2015 11:34 PM, Dave Chinner wrote: >>>> On Thu, Aug 06, 2015 at 10:52:47AM +0300, Boaz Harrosh wrote: >>>>> On 08/06/2015 06:24 AM, Dave Chinner wrote: >>>>>> On Wed, Aug 05, 2015 at 09:42:54PM -0400, Linda Knippers wrote: >>>>>>> On 08/05/2015 06:01 PM, Dave Chinner wrote: >>>>>>>> On Wed, Aug 05, 2015 at 04:19:08PM -0400, Jeff Moyer wrote: >>>>> <> >>>>>>>>> >>>>>>>>> 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. >>>>>>>> >>>>> >>>>> This part I do not understand. how is mkfs.xfs reading the sector? >>>>> Is it through open(/dev/pmem0,...) ? O_DIRECT? >>>> >>>> mkfs.xfs uses O_DIRECT. Only if open(O_DIRECT) fails or mkfs.xfs is >>>> told that it is working on an image file does it fall back to >>>> buffered IO. All of the XFS userspace tools work this way to prevent >>>> page cache pollution issues with read-once or write-once data during >>>> operation. > .... >> That patch does cause 'mkfs -t xfs' to work. >> >> Before: >> $ sudo mkfs -t xfs -f /dev/pmem3 >> meta-data=/dev/pmem3 isize=256 agcount=4, agsize=524288 blks >> = sectsz=512 attr=2, projid32bit=1 > ^^^^^^^^^^ > .... > >> $ sudo mkfs -t xfs -f /dev/pmem3 >> meta-data=/dev/pmem3 isize=256 agcount=4, agsize=524288 blks >> = sectsz=4096 attr=2, projid32bit=1 > ^^^^^^^^^^^ > > So in the after case, mkfs.xfs is behaving differently and not > exercising the bug. It's seen the: > >> $ cat /sys/block/pmem3/queue/logical_block_size >> 512 >> $ cat /sys/block/pmem3/queue/physical_block_size >> 4096 > ^^^^ > > 4k physical block size, and hence configured the filesystem with a > 4k sector size so all IO it issues is physicallly aligned. IOWs, > mkfs.xfs's last sector read is 4k aligned and sized, and therefore > the test has not confirmed that the patch fixes the 512 byte last > sector read is fixed at all. That is true. All I reported is that mkfs.xfs now works. I had some questions about whether that was right. The underlying problem is still there, as I can demonstrate with a simple reproducer that just does what mkfs.xfs would have done before. > Isn't there a regression test suite that covers basic block device > functionality that you can use to test these simple corner cases? If there is, seems like DAX adds a few twists. -- ljk > > Cheers, > > Dave. > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
