Messages in this thread |  | | | Date | Mon, 21 Nov 2005 19:47:30 -0800 | | From | Andrew Morton <> | | Subject | Re: Please help me understand ->writepage. Was Re: segfault mdadm --write-behind, 2.6.14-mm2 (was: Re: RAID1 ramdisk patch) |
| |
Neil Brown <neilb@suse.de> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |