Cc: Pekka Enberg <penberg@...>, Ryan Finnie <ryan@...>, Andrew Morton <akpm@...>, <linux-kernel@...>, <linux-fsdevel@...>, <cjwatson@...>, <linux-mm@...>
Sorry for my delay, here are a few replies.
On Sun, 14 Oct 2007, Erez Zadok wrote:
Thanks, Pekka, yes that made a lot of sense.
I think that's inappropriate. Why should unionfs_writepage re-mark its
page as dirty when the lower level does so? Unionfs has successfully
done its write to the lower level, what the lower level then gets up to
(writing then or not) is its own business: needn't be propagated upwards.
The fewer places that supply AOP_WRITEPAGE_ACTIVATE the better.
What I'd like most of all is to eliminate it, in favour of vmscan.c
working out the condition for itself: but I've given that no thought,
it may not be reasonable.
unionfs_writepage also sets AOP_WRITEPAGE_ACTIVATE when it cannot
find_lock_page: that case may be appropriate. Though I don't really
understand it: seems dangerous to be relying upon the lower level page
just happening to be there already. Isn't memory pressure then likely
to clog up with lots of upper level dirty pages which cannot get
written out to the lower level?
I think not.
You're both agreed on that, but I don't see how: ecryptfs writes the
lower level via vfs_write, it's not using the lower level's writepage,
is it?
Hugh
-
