On Fri, May 05, 2006 at 07:21:48PM -0700, Andrew Morton wrote:
> > On Fri, 2006-05-05 at 10:22 -0500, Dave Kleikamp wrote:
> > > I understand this comes from the FiST package. In that code,
> > > there is a comment in one of these functions explaining the
> > > second read. It would be nice to have that comment in here too:
> > >
> > > /*
> > > * call readpage() again if we returned from wait_on_page with a
> > > * page that's not up-to-date; that can happen when a partial
> > > * page has a few buffers which are ok, but not the whole
> > > * page.
> > > */
...
> And why doesn't it cause do_generic_mapping_read() and
> page_cache_read() to fail?
>
> This is all raher fishy.
I asked Erez about this; I will try to accurately summarize his
response. He indicated that, about 5 or so years ago, when ext2/3's
block size was set to 1K or 2K, but the page size was 4K, they found
that it was possible to get a page which had some of the blocks in the
bufcache, while other blocks were not.
Their solution at the time was to just read again, and that seemed to
fix the problem for them. It was not obvious as to why things were
happening that way, and it may be the case that the second read is no
longer necessary in the current kernel.
Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
