Cc: Andrew Morton <akpm@...>, Chris Mason <chris.mason@...>, Christian Borntraeger <borntraeger@...>, <linux-mm@...>, <linux-kernel@...>, Martin Schwidefsky <schwidefsky@...>, Theodore Ts'o <tytso@...>, <stable@...>
I read a representative sample of the relevant tools before replying
to Andrew.
That was my feeling that we could simplify things. The block layer
page cache operations certainly.
I know in the filesystems that use the buffer cache like reiser and
JBD they could stop worrying about the buffers becoming mysteriously
dirty. Beyond that I think there is a lot of opportunity I just
haven't looked much yet.
The rd.c code is perfectly valid if someone wasn't forcing buffer
heads on it's pages. It is a conflict of expectations.
Regardless I didn't do it as a kneejerk and I don't think that
patch should be merged at this time. I proposed it because as I
see it that starts untangling the mess that is the buffer cache.
rd.c was just my entry point into understanding how all of those
pieces work. I was doing my best to completely explore my options
and what the code was doing before settling on the fix for rd.c
Yes.
Yes. Although they will at least get the guarantee that no one
else is dirtying their pages at strange times.
Not that so much as the order in which things go into the cache
does not match the order the blocks go to disk.
Yes. I was thinking of dump or something like that here. Where
we simply read out the data and try to make some coherent sense
of it. If we see a version of the metadata that points to things
that have not been finished yet or is in the process of being
written to that could be a problem.
When going through the buffer cache as far as I can tell people
don't use little things like page lock when writing data so
the page cache reads can potentially race with what should
be atomic writes.
Eric
-
