[lkml]   [2000]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: The INN/mmap bug

On Mon, 18 Sep 2000, Alexander Viro wrote:
> We might as well do it in create_empty_buffers(), FWIW. Do you see any
> case when it would mean extra work? I'm thinking about the following:
> if (page is uptodate)
> do get_block(...,0) for all buffers and mark them uptodate
> in the end of buffer-ring creation. Comments?

The above _will_ cause extra work, notably for the case of writing to a
hole (first create_empty_buffers() will do the get_block( .., 0) and get a
zero, then the writing will do a get_block( .., 1) to actually allocate
the block.

We could push the "create" thing into create_empty_buffers(), though. We'd
give it a "begin,end" the way writing wants, and a reader (or truncate)
would just pass in 0,0.

Hmmm.. I like that approach - because I suspect that eventually we want to
change the FS mapping function away from the current buffer-based one, and
make it a page-based one to let the low-level filesystem handle the tail
etc issues itself.

And when we do that, we'd have to pass in that "I'm going to want to dirty
this range" information anyway, and the current "create_empty_buffers()"
would in fact become the new "map this page, please" function.

At that point, block_write_full_page() would become something like

unsigned long index = inode->i_size >> PAGE_CACHE_SHIFT;

offset = inode->i_size & (PAGE_CACHE_SIZE-1);
if (index > page->index)

create_empty_buffers(page, 0, offset);
for_each_buffer(page) {
if (buffer_mapped(bh))

which would certainly be simpler than the current code. Hmm.


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

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