On Thu, Oct 4, 2018 at 7:38 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > On Thu, Oct 04, 2018 at 01:14:12AM +0200, Miklos Szeredi wrote: >> On Thu, Oct 4, 2018 at 12:59 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: >> > overlay >> > lower_fs >> > loopback dev >> > loop img fs >> > >> > And freeze the loop img fs, overlay can still get stuck in it's >> > shrinker because the the lower_fs gets stuck doing IO on the frozen >> > loop img fs. >> > >> > i.e. it's the same issue - kswapd will get stuck doing reclaim from >> > the overlay shrinker. >> >> Is overlay making the situation any worse in this case? IOW, would > > No, it's not. My point is that it's the same layering problem, not > that it is an issue unique to overlay. Fixing one without addressing > the other does not make the problem go away. But you were suggesting that this should be solved by somehow preventing the shrink after unlink issue in overlayfs. But the freeze dependency is not unique to that: if filesystem A is frozen and a file in that fs is loopback mounted in filesystem B then B also needs to be frozen before A is frozen to prevent deadlocking through kswapd. Both could be solved by creating a new "struct freeze_dep" object with ->freeze/unfreeze methods, that can be embedded into overlay and loopback device and whatever else, and which is installed onto a "struct list_head s_freeze_deps" list in the superblock. Does that make sense? > >> >> If vfs stores a reverse tree of stacked fs dependencies, then individual >> >> sb freeze can be solved. >> > >> > Don't make me mention bind mounts... :/ >> >> How do mounts have anything to do with this? > > Bind mounts layer superblocks in unpredictable manners. e.g. the > lowerfs for overlay could be a directory heirachy made up of > multiple bind mounts from different source filesystems. So it's not > just a 1:1 upper/lower superblock relationship it could be 1:many. > Dependency graphs get complx quickly in such configurations. Overlayfs avoids that sort of mess by not overlaying mount trees, just single mounts. > My point is that it's not obvious that there is a simple, clear > dependency hierarchy between superblocks because there are so many > ways they can be layered by userspace and layered fileystems and > block devices. For overlay and loopback there's a simple dependency graph. As for stacked block devs, I have no idea if such an infrastructure makes sense or is possible at all. Thanks, Miklos
