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. 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. Drawing the fire away from overlayfs.. I personally find the behavior that a process that only has files open for read could block when filesystem is frozen somewhat unexpected to users (even if I can expect it). I wonder out loud if it wouldn't be friendlier for any filesystem to defer "garbage collection" (e.g. truncate deleted inode blocks) to thawing time, just as those operations are already run on mount (post crash) anyway. Thanks, Amir.
