From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boaz Harrosh Subject: Re: regression introduced by "block: Add support for DAX reads/writes to block devices" Date: Mon, 10 Aug 2015 10:42:13 +0300 Message-ID: <55C855D5.1070001@plexistor.com> References: <100D68C7BA14664A8938383216E40DE04091408C@FMSMSX114.amr.corp.intel.com> <100D68C7BA14664A8938383216E40DE0409144D9@FMSMSX114.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: "linda.knippers@hp.com" , "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" To: Jeff Moyer , "Wilcox, Matthew R" Return-path: Received: from mail-wi0-f180.google.com ([209.85.212.180]:35098 "EHLO mail-wi0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752814AbbHJHmQ (ORCPT ); Mon, 10 Aug 2015 03:42:16 -0400 Received: by wicne3 with SMTP id ne3so11345695wic.0 for ; Mon, 10 Aug 2015 00:42:15 -0700 (PDT) In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 08/07/2015 11:41 PM, Jeff Moyer wrote: <> > >> We need to cope with the case where the end of a partition isn't on a >> page boundary though. > > Well, that's usually done by falling back to buffered I/O. I gave that > a try and panicked the box. :) I'll keep looking into it, but probably > won't have another patch until next week. > lets slow down for a sec, please. We have all established that an unaligned partition start is BAD and not supported? (If we want to also support this, which is possible then all the below is mute) Well we do know that any real pmem device will actually be 128M aligned because of how the DIMM thing work. So any start-aligned partition means length aligned as well. (Emulated pmem is 4k aligned as well) That said, you might want to protect against unaligned start / length. Even though we have the 4k physical sector patch, a forced fdisk could produce such a partition. I would suggest that for such un-aligned partitions the code in bdev that sets IS_DAX on the bdev-inode should only do so if the start / length is aligned. Else it becomes a !IS_DAX inode and all is fine. Users will learn soon enough that for dax you need to keep the recommended 4k alignments. In the DAX filesystem case the start-un-aligned case is fatal and the FS would not mount (dax enabled) . The length-un-aligned case is not a problem because the 4k block size mandatory for dax will trim the device length to an FS block boundary. So it is only a problem with RAW bdev inodes and I would just not let it be IS_DAX in the un-aligned case. (or trim its size) Thanks Boaz > Cheers, > Jeff