Neil Brown <[email protected]> wrote:
>
> Help ???
Indeed. tmpfs is crackpottery.
> What md/bitmap wants to do is effectively memory map the file, make
> updates to pages occasionally, flush those pages out to storage, and
> wait for the flush to complete. It doesn't exactly memory map. It
> just reads all the pages and keeps them in an array (holding a
> reference to each).
>
> To write the pages out it effectively does ->prepare_write,
> ->commit_write, and then ->writepage.
> I'm not sure that prepare/commit is needed, but they don't seem to be
> the problem. writepage is.
>
> For tmpfs at least, writepage disconnects the page from the pagecache
> (via move_to_swap_cache), so the page that we are holding is no longer
> part of the file and, significantly, page->mapping become NULL.
> This suggests that the ->writepage usage is broken.
> However I tried to see what 'msync' does for real memory mapped files,
> and it eventually calls ->writepage too. So how does that work??
>
> Any advice would be most welcome!
Skip the writepage if !mapping_cap_writeback_dirty(page->mapping), I guess.
Or, if appropriate, just sync the file. Use filemap_fdatawrite() or even
refactor do_fsync() and use most of that.
Also, write_page() doesn't need to run set_page_dirty(); ->commit_write()
will do that.
Several kmap()s in there which can become kmap_atomic().
bitmap_init_from_disk() might be leaking bitmap->filemap on kmalloc-failed
error path.
bitmap->filemap_attr can be allocated with kzalloc() now.
-
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]
