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: > > On Wed, Oct 03, 2018 at 06:45:13AM +0300, Amir Goldstein wrote: > >> On Wed, Oct 3, 2018 at 2:14 AM Dave Chinner <david@xxxxxxxxxxxxx> wrote: > >> [...] > >> > > Seems like freezing any of the layers if overlay itself is not frozen > >> > > is not a good idea. > >> > > >> > That's something we can't directly control. e.g. lower filesystem is > >> > on a DM volume. DM can freeze the lower fileystem through the block > >> > device when a dm command is run. It may well be that the admins that > >> > set up the storage and filesystem layer have no idea that there are > >> > now overlay users on top of the filesystem they originally set up. > >> > Indeed, the admins may not even know that dm operations freeze > >> > filesystems because it happens completely transparently to them. > >> > > >> > >> I don't think we should be binding the stacked filesystem issues with > >> the stacked block over fs issues. > > > > It's the same problem. Hacking a one-off solution to hide a specific > > overlay symptom does not address the root problem. And, besides, if > > you stack like this: > > > > 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. > >> 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. You can also have the same superblock above overlay through a bind mount as well as below as the lower fs. e.g. A user could freeze the bind mounted heirarchy after checking it's a different device to the filesystem they are also writing to (e.g. logs to "root" device, freezes "home" device). IOWs, they could be completely unaware that the freeze target is the same filesystem that underlies the "root" device, and so when the freeze the "home" target their root device also freezes. That sort of thing registers high up on the user WTF-o-meter, and it's not at all obvious what went wrong or how to get out of that mess. It's not clear to me if bind mounts should accept path based superblock admin commands like freeze because the potentially expose problems far outside the realm that specific user/mount namespace is allowed access to. 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. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
