Remount / with barrier=0 when fstype is ext4

[guns]

Numerous people¹ have reported that echo mem > /sys/power/state fails to suspend their machines. This is likely due to the following ext4 commit², which was created to increase data integrity:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=06a407f13daf9e48f0ef7189c7e54082b53940c7

kernel/power/suspend.c:pm_suspend() calls sys_sync() during sleep preparation, which in turn calls fs/ext4/super.c:ext4_sync_fs(). After the above commit, if the sbi->s_journal->j_flags & JBD2_BARRIER condition returns >0, a final flush + wait is called on the underlying block device.

Since the block device is the one we just suspended with luksSuspend, the call hangs indefinitely and the machine never enters sleep.

Mounting an ext4 fs with the barrier=0 or nobarrier option avoids this lockup.

The corresponding ext3 sync fn does not appear to be affected, but this is untested.

¹ @seanlynch in issue #2, a user on the AUR project page, and a Red Hat user in the following bug report:

https://bugzilla.redhat.com/show_bug.cgi?id=1013304#c0

PATCH NOTES:

I changed the #! to /bin/bash to take advantage of the local statement and the ${VAR:i:n} expansion; I am happy to revert these back to POSIX equivalents if /bin/sh compat is important to you.

Thanks!

[vianney]

Many thanks for finding this out and sending the patch. This issue indeed made the whole script pointless, but I did not have time to investigate. I fear such issues will pop up once in a while.

Anyway, it seems to be again working fine for now. Thanks a lot.