Re: Please help me understand ->writepage. Was Re: segfault mdadm--write-behind, 2.6.14-mm2 (was: Re: RAID1 ramdisk patch)

[Andrew Morton]

Neil Brown <neilb@xxxxxxx> wrote:
>
> Uhm, what would you think of testing mapping_cap_writeback_dirty in
>  write_one_page??  If you don't like it, I can take it into write_page.

write_one_page() is a little library function for filesystems to call, and
filesystems implicitly know whether or not they have backing store.  So
probably it's best to do this test in the (unusual) caller.

> > Also, write_page() doesn't need to run set_page_dirty(); ->commit_write()
> > will do that.
>
> Ok.... but I think I'm dropping prepare_write / commit_write.
>

Those functions do some pretty handy things, like creating disk blocks
within the file to back the page.  If someone comes along and ftruncate()s
the bitmap file while you're not looking, what happens?  Generally we use
i_sem for this sort of thing.


If you know that the page is still mapped into the file then yes, you can do

	lock_page()
	kmap_atomic()
	<modify>
	kunmap_atomic()
	flush_dcache_page()
	set_page_dirty()
	unlock_page()
	write_one_page(wait==1)

but that's rather a lot of work.

bitmap_unplug() looks risky - calling filesystem functions (like
lock_page()) from inside an unplug function.  Can this all be called from
the vmscan->writepage path?

It might be simpler and more maintainable to maintain the bitmap in normal
kernel memory, sync it to disk via higher-level entrypoints like
sys_write(), vfs_write(), sys_sync(), do_sync(), etc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/