From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH v2] Do a proper locking for mmap and block size change Date: Fri, 30 Nov 2012 11:36:01 -0500 Message-ID: <20121130163601.GA32238@infradead.org> References: <20121129191503.GB3490@shiny> <20121129194840.GC3490@shiny> <20121129212931.GD3490@shiny> <20121130024910.GF6434@dastard> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Linus Torvalds , Chris Mason , Chris Mason , Mikulas Patocka , Al Viro , Jens Axboe , Jeff Chua , Lai Jiangshan , Jan Kara , lkml , linux-fsdevel To: Dave Chinner Return-path: Content-Disposition: inline In-Reply-To: <20121130024910.GF6434@dastard> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, Nov 30, 2012 at 01:49:10PM +1100, Dave Chinner wrote: > > Ugh. That's a big violation of how buffer-heads are supposed to work: > > the block number is very much defined to be in multiples of b_size > > (see for example "submit_bh()" that turns it into a sector number). > > > > But you're right. The direct-IO code really *is* violating that, and > > knows that get_block() ends up being defined in i_blkbits regardless > > of b_size. > > Same with mpage_readpages(), so it's not just direct IO that has > this problem.... The mpage code may actually fall back to BHs. I have a version of the direct I/O code that uses the iomap_ops from the multi-page write code that you originally started. It uses the new op as primary interface for direct I/O and provides a helper for filesystems that still use buffer heads internally. I'll try to dust it off and send out a version for the current kernel.