lkml.org 
[lkml]   [2004]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH] problem of cont_prepare_write()
    OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> wrote:
    >
    >
    > status = __block_prepare_write(inode, new_page, zerofrom,
    > PAGE_CACHE_SIZE, get_block);
    > if (status)
    > goto out_unmap;
    > kaddr = kmap_atomic(new_page, KM_USER0);
    > memset(kaddr+zerofrom, 0, PAGE_CACHE_SIZE-zerofrom);
    > flush_dcache_page(new_page);
    > kunmap_atomic(kaddr, KM_USER0);
    > __block_commit_write(inode, new_page,
    > zerofrom, PAGE_CACHE_SIZE);
    > unlock_page(new_page);
    > page_cache_release(new_page);
    > }
    >
    > But until ->commit_write(), kernel doesn't update the ->i_size. Then,
    > if kernel writes out that hole page before updates of ->i_size, dirty
    > flag of buffer_head is cleared in __block_write_full_page(). So hole
    > page was not writed to disk.

    Oh I see. After the above page is unlocked, it's temporarily outside
    i_size.

    Perhaps cont_prepare_write() should look to see if the zerofilled page is
    outside the current i_size and if so, advance i_size to the end of the
    zerofilled page prior to releasing the page lock.

    We might need to run mark_inode_dirty() at some stage, or perhaps just rely
    on the caller doing that in ->commit_write().
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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