Messages in this thread | | | Date | Tue, 21 Feb 2006 10:16:38 +1100 | From | Nathan Scott <> | Subject | Re: [PATCH 0/3] map multiple blocks in get_block() and mpage_readpages() |
| |
On Mon, Feb 20, 2006 at 03:06:11PM -0800, Badari Pulavarty wrote: > On Tue, 2006-02-21 at 08:59 +1100, Nathan Scott wrote: > ... > > I wonder if this change will end up ruining things for the lunatic > > fringe issuing these kinds of IOs? Maybe the get_block call could > > take a block count rather than a byte count? > > Yes. I thought about it too.. I wanted to pass "block count" instead > of "byte count". Right now it does .. > > bh->b_size = 1 << inode->i_blkbits; > call get_block(); > > First thing get_block() does is > blocks = bh->b_size >> inode->i_blkbits; > > All, the unnecessary shifting around for nothing :(
Yeah, pretty silly really, but theres not much choice if the goal is to keep this simple. Oh well.
> But, I ended up doing "byte count" just to avoid confusion of > asking in "blocks" getting back in "bytes".
Understood.
> I have no problem making b_size as "size_t" to handle 64-bit. > But again, if we are fiddling with buffer_head - may be its time > to look at alternative to "buffer_head" with the information exactly > we need for getblock() ?
That is a much bigger change - I'm not in a position to make the call on whether thats in everyones best interests. However, I do want to make sure we don't regress anything, so I guess the u32 to size_t switch probably should be made to resolve this issue.
Thanks again for following up on this.
cheers.
-- Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |