On Mon, 30 Aug 2010, Neil Brown wrote: > > You didn't mention one possibility: add limitations that prevent the > > weird corner cases arising. I believe this is the simplest option. > > Val has been following that approach and asking if it is possible to make an > NFS filesystem really-truly read-only. i.e. no changes. > I don't believe it is. Perhaps it doesn't matter. The nasty cases can be prevented by just disallowing local modification. For the rest NFS will return ESTALE: "though luck, why didn't you follow the rules?" > > I think *notify will work correctly, every modificaton will be > > notified on both the union fs and the upper fs. But I haven't tested > > this yet. > > I tried. It doesn't. > To be precise: directory changes like file creation (even creation of a file > that already exists) get notified, but purely file-based event like modifying > the contents of the file don't generate events back to the overlayfs > directory. > Because an open (for write) of a file is passed through to the upper > filesystem, the notifications of modification through that open only go to the > upper filesystem. Ah, right. > > > I think the way to fix this would involve the union-fs putting a > > > notifier on the upper dir to match whatever is on the > > > merged-dir. However the filesystem currently isn't told when > > > notifiers are attach to an inode. I think it would be good to > > > add an inode_operation which is called whenever the notifiers > > > are changed. This would also allow a networked filesystem to > > > report notification if the protocol supported it. Does that > > > seem reasonable? In that light this sounds entirely reasonable. Thanks, Miklos -- 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
