[lkml]   [2006]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 10/13: eCryptfs] Mmap operations
    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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-05-06 18:08    [W:0.020 / U:3.756 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site