On Jan 8 2007 15:51, Erez Zadok wrote: > >BTW, this is a problem with all stackable file systems, including >ecryptfs. To be fair, our Unionfs users have come up against this >problem, usually for the first time they use Unionfs :-). Then we >tell not to do that, but that if they have to, to run "uniondbg -g" >afterward to force a flushing of Unionfs caches. This practical >suggestion worked well for our Unionfs users so far. Speaking of practicality, would not it be easiest to add a mount-time option that says "don't ever cache"? Or perhaps "enable cache, I assure you I don't fiddle with the lower layer". >Another possibility is that after, hopefully, both Unionfs and >ecryptfs are in, and some more user experience has been accumulated, >that we'll look into addressing this page-cache consistency problem >for all stacked f/s. Not that I know much about memory handling, but...: When a process writes to a file, the write is cached by default. If now an origin tag (as in: a struct member) is attached to this cached object, unionfs/VFS can decide whether the last write access has happened from within unionfs or something else, and act accordingly, namely (1) flush when origin tag is not "unionfs" (2) do as usual like today's unionfs. Think of it like a "last changed by"-attribute. -`J' -- - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
