lkml.org 
[lkml]   [2000]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Still ext2-corruption in test8-pre5 (incl. OOPS)


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 fix
for 2.4.x.

I think it makes most sense as a complete change of interface: instead of
asking the filesystem for the blocknumber, we could ask the filesystem to
generate 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 IO
unit that isn't even aligned with a 4kB page, for example. It's
potentially valid to have each page split up into 1kB+2kB+1kB requests,
because the filesystem really might be a 2kB system but for some strange
reason isn't doing aligned buffers or whatever.

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

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 semantics
inside the loop. So it would basically boil down to either macros or to
passign 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 Jeff
that he just remove the check.

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

Linus

-
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/

\
 
 \ /
  Last update: 2005-03-22 12:39    [W:2.225 / U:0.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site