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 reclaim on fs-over-loopback not have the same issue *without* overlay? If not, why? >> The latter is more complex to solve >> generally and has by design non limited stack depth. The former has >> limited stack depth (2) and each sb knows its own stack depth, which >> is already used in overlay to annotate lockdep correctly. >> >> 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? We are talking about filesystem (i.e. superblock) dependencies, not mount dependencies (which would make zero sense anyway). Thanks, Miklos
