Well, then you have to watch out for insmod...
> - Have create_buffers try for all the buffers it needs, and if it doesn't
> get them all, put them all back and go to sleep on &buffer_wait until
> more come available.
>
> The latter is probably easier. It takes the sleep out of
> get_unused_buffer_head and moves it into create_buffers.
> Moving the sleep into create_buffers when building an async request
> would work, and might be better if you have a wide mix of block sizes.
> (create_buffers is the only client of get_more_buffer_heads, so it
> shouldn't matter where the sleep occurs.) But this would involve
> tearing down partially built buffers. I'll give this some further
> thought.
You could also have create_buffers return short. It's guaranteed to
return at least one buffer, but it might not return them all. On
unlock_buffer, look for the last address the I/O was done on, and if
it's not the end of the page, move the buffer head being unlocked down
and start a new I/O. (Is this a stack overflow risk if the I/O
is satisfied synchronously ll_rw_block?)
> Thanks for your helpful comments!
I'm glad to use what I've been learning to help! I'll update
Documentation/vfs.txt when I figure out the dcache and a few more
confusing things. (Why does nobody implement writepage()?
mm/filemap.c seems to just use write().)
For example, I've just learned that bh->b_this_page != NULL and
test_bit(BH_FreeOnIO, &bh->b_state) are NOT synonomous, as for
some sorts of page-in, the buffer heads are left around...
see mm/filemap.c:filemap_write_page() (and the comment therein
by guess who).
Um, silly question: has the mem_map[MAP_NR(page)].buffers != NULL
case gone away, as I don't see where it's created, and thus the "race"
isn't an issue? Or am I missing something?
-- -Colin