Messages in this thread |  | | Date | Tue, 5 Sep 2000 23:09:34 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: Still ext2-corruption in test8-pre5 (incl. OOPS) |
| |
On Tue, 5 Sep 2000, Linus Torvalds wrote:
> We just grab the page, populate it with buffers if required, and find the > one buffer that we need to clear out. We clear it out and mark it dirty. > End of story. > > NOTE: Udo, because I haven't actually tested this (it may not actually > compile etc small details), you probably shouldn't actually test this out > as-is unless you are _really_ daring and don't mind fixing up after me. > It's more a "this is how it should work" kind of thing. > > Al? Mind giving it a quick look?
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 * "make sure that ->buffers is there and map the buffers in given range" is too fscking common and deserves a function of its own. * 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'll play with #2 and see what can be done there. I have a funny feeling that lots of things will merrily factor out, so we may end up with ability to do 10-liner transition to kiobuf whenever we will decide to do it.
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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |