Neil Brown <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
