Hi! On Sun 20-07-25 22:23:36, Askar Safin wrote: > I did experiments on my laptop, and these experiments show that this > patchset does not solve various longstanding problems related to suspend > and filesystems. (Even if I enable /sys/power/freeze_filesystems ) > > Now let me describe problems I had in the past (and still have!) and then > experiments I did and their results. > > So, I had these 3 problems: > > - Suspend doesn't work if fstrim in progress (note that I use btrfs as > root file system) Right, this is expected because the FITRIM ioctl (syscall as any other) likely takes too long and so the suspend code looses its patience. There's nothing VFS can do about this. You can talk to btrfs developers to periodically check for pending signal / freezing event like e.g. ext4 does in ext4_trim_interrupted() to avoid suspend failures when FITRIM is running. > - Suspend doesn't work if scrub in progress Similar situation as with FITRIM. This is fully in control of the filesystem and unless the filesystem adds checks and early abort paths, VFS cannot do anything. > - Suspend doesn't work if we try to read from fuse-sshfs filesystem while > network is down On the surface the problem is the same as the above two but the details here are subtly different. Here I expect (although I'm not 100% sure) the blocked process is inside the FUSE filesystem waiting for the FUSE daemon to reply (a /proc/<pid>/stack of the blocked process would be useful here). In theory, FUSE filesystem should be able to make the wait for reply in TASK_FREEZABLE state which would fix your issue. In any case this is very likely work for FUSE developers. So I'm sorry but the patch set you speak about isn't supposed to fix any of the above issues you hit. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
