On Tue, 5 Sep 2000, Alexander Viro wrote:> > It looks OK, except for the following (issues are actually common to> all block_... functions):> * if we ever do allocation unit != IO block size (have to do it on> UFS, probably want it on ext2 to break 4Kb limit) we'll have to deal with> more than one block. Not a big deal, but worth getting it right

Yeah, but that's a much bigger issue. Not something we can or want to fixfor 2.4.x.

I think it makes most sense as a complete change of interface: instead ofasking the filesystem for the blocknumber, we could ask the filesystem togenerate the buffer list for that page.

Your other this would be solved by this too:

> * with some filesystems we really want an analog of get_block()> acting on array. Aside of UFS, FAT-derived filesystems are obvious candidates.> I mean, WTF? Why bother recalculating the thing if allocation unit is larger> than IO unit?

I don't think it's about being a larger IO unit - it can be a smaller IOunit that isn't even aligned with a 4kB page, for example. It'spotentially valid to have each page split up into 1kB+2kB+1kB requests,because the filesystem really might be a 2kB system but for some strangereason isn't doing aligned buffers or whatever.

The issue of a "tail" is the same thing. A 2kB block filesystem with a 512byte tail, so a page might be 2kB+512B+unmapped if it is at the end of thefile.

But right now there's no way we'd make _those_ kinds of changes. In fact,right now I'd be happy to just have a working truncate() for a change ;)

> * "make sure that ->buffers is there and map the buffers in given> range" is too fscking common and deserves a function of its own.

Yeah, maybe. It's just that every single case has different semanticsinside the loop. So it would basically boil down to either macros or topassign around function pointers..

> BTW, Jeff's complaint about size restriction in ll_rw_block() is> valid. It made sense when we used the thing only for buffer-cache, but> these days it looks bogus. It doesn't work as alias-prevention anymore, so> there's little point in doing it.

Oh, I agree completely. What you didn't see me was me suggesting to Jeffthat he just remove the check.

It turns out that apparently several low-level drivers complain at thatpoint, so it's more than just that single test, though.

Linus

-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.kernel.orgPlease read the FAQ at http://www.tux.org/lkml/