---- 在 星期四, 2020-10-15 12:57:41 Al Viro <viro@xxxxxxxxxxxxxxxxxx> 撰写 ---- > On Thu, Oct 15, 2020 at 11:42:51AM +0800, Chengguang Xu wrote: > > ---- 在 星期四, 2020-10-15 11:25:01 Al Viro <viro@xxxxxxxxxxxxxxxxxx> 撰写 ---- > > > On Sat, Oct 10, 2020 at 10:23:51PM +0800, Chengguang Xu wrote: > > > > Currently there is no notification api for kernel about modification > > > > of vfs inode, in some use cases like overlayfs, this kind of notification > > > > will be very helpful to implement containerized syncfs functionality. > > > > As the first attempt, we introduce marking inode dirty notification so that > > > > overlay's inode could mark itself dirty as well and then only sync dirty > > > > overlay inode while syncfs. > > > > > > Who's responsible for removing the crap from notifier chain? And how does > > > that affect the lifetime of inode? > > > > In this case, overlayfs unregisters call back from the notifier chain of upper inode > > when evicting it's own inode. It will not affect the lifetime of upper inode because > > overlayfs inode holds a reference of upper inode that means upper inode will not be > > evicted while overlayfs inode is still alive. > > Let me see if I've got it right: > * your chain contains 1 (for upper inodes) or 0 (everything else, i.e. the > vast majority of inodes) recepients > * recepient pins the inode for as long as the recepient exists > > That looks like a massive overkill, especially since all you are propagating is > dirtying the suckers. All you really need is one bit in your inode + hash table > indexed by the address of struct inode (well, middle bits thereof, as usual). > With entries embedded into overlayfs-private part of overlayfs inode. And callback > to be called stored in that entry... > Yeah, actually that could implement the logic but I'm afraid of performance degradation caused by lock contention of hash table in concurrent file write because in practice we build up hundreds of overlayfs instances on same underlying filesystem. Thanks, Chengguang
