From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752623AbbHMOAK (ORCPT ); Thu, 13 Aug 2015 10:00:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34551 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751820AbbHMOAI (ORCPT ); Thu, 13 Aug 2015 10:00:08 -0400 From: Jeff Moyer To: Boaz Harrosh Cc: "Wilcox\, Matthew R" , "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> <100D68C7BA14664A8938383216E40DE0409144D9@FMSMSX114.amr.corp.intel.com> <55C855D5.1070001@plexistor.com> <55CC2BDA.3080906@plexistor.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, 13 Aug 2015 10:00:06 -0400 In-Reply-To: <55CC2BDA.3080906@plexistor.com> (Boaz Harrosh's message of "Thu, 13 Aug 2015 08:32:10 +0300") 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 Boaz Harrosh writes: > On 08/13/2015 12:11 AM, Jeff Moyer wrote: >> Boaz Harrosh writes: >> >>> 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? >> >> No. Unaligned partitions on RAID arrays or 512e devices are bad because >> they result in suboptimal performance. They are most certainly still >> supported, though. >> > > What ? > > I meant for dax on pmem or brd. I meant that we *do not* support dax access > on an unaligned partition start. (None dax is perfectly supported) Sorry, I thought your statement was broader than that. > We did it this way because of the direct_access API that returns a pfn > with is PAGE_SIZE. We could introduce a pfn+offset but we thought it is > not worth it, and that dax should be page aligned for code simplicity I'd be fine with changing the persistent memory block device to only support 4k logical, 4k physical block size. That probably makes the most sense. Cheers, Jeff