On Mon, Aug 07, 2006 at 04:35:23PM -0400, John T. Kohl wrote: > >>>>> "Josef" == Josef Sipek <jsipek@xxxxxxxxxxxxxxxxx> writes: > > Josef> That is an artifact of how the Linux VFS works. When you modify a > Josef> file though wrapfs (or any other stackable file system) the > Josef> wrapfs code gets called. It then calls the lower file system code > Josef> on your behalf. When you modify the lower file directly, ext3 > Josef> gets the called, but since Linux has no way for this change to be > Josef> announced up the stack, wrapfs happily uses the old, cached > Josef> data. If you have ideas about how to solve this, please share > Josef> them - right now, there is a lot of work being done to get > Josef> Unionfs (ours) and eCryptfs into the vanilla linux kernel. > > While constructed for a vnode system, the ideas in a set of > Ficus-related papers and theses could be helpful here. This is John > Heidemann's PhD thesis on the topic (covers necessary VM designs, > callbacks, etc.): > http://www.isi.edu/people/johnh/PAPERS/Heidemann95e.html I have read the SOSP '95 paper by the same author a while back (I skimmed thought the paper you linked to, and it looks like chapters 6-8 cover the SOSP paper material) and I'd like to point out that such architecture is not trivial to implement - at least as described by the paper. There are, however, few interesting ideas there that might be worth looking into. I think that the current thinking is, let's get ecyptfs/unionfs out there, and then let's fix what _needs_ to be fixed, instead of redoing the page cache from the ground up. Sure, we might end up with something similar to what the paper describes, but "Linux is evolution, not intelligent design." Thanks for the link, Josef "Jeff" Sipek. -- Bus Error: passangers dumped. - 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
