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:0.073 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site