RFE: Better lock handling about shake

[unbrice]

Locks in Linux can be "advisory" (user space can ignore them) or "mandatory". Mandatory locks can expire, create responsiveness problems and will go away. Advisory locks are typically ignored by user space programs.
I am not aware of xfs_fsr and btrfs defrag having a way around that. I expect that they take advisory locks, or no lock.

Currently we:

• Take mandatory lock
• Copy to temporary throw-away file
• Copy temporary file back over original file ⚠️
• Release locks

I propose not to rely just on mandatory locking for safety, and make the mandatory locked section much shorter. Instead I propose to:

1. Take advisory locks on the file about to be defrag'd.
2. Create an anonymous file in the same directory with open(..., O_TMPFILE).
3. Copy the defrag'd file over the temporary like the last copy does currently.
4. Try taking mandatory locks over the defrag'd file, just in case, but don't fail if they can't be acquired
5. Use heuristics to check the defrag'd file wasn't changed (atime, mtime, file size, checksum of first and last MB)
6. Swap temporary file defrag'd file renameat2(..., RENAME_EXCHANGE) ⚠️
7. Do a last check of heuristics, show a warning message if they don't pass
8. Release locks

This is better because:

• If mandatory locks are supported, it's quite safe to assume the atomic exchange can happen before lease-break-time
• If they are not, software honoring advisory locks are still supported (softwares like Gnome Tracker or other accessing files that are not theirs should honor locks)
• Other softwares are unlikely to encounter problems since the critical section is short but the worse that can happen is to be left with an older version of the file.

What do you think?

[unbrice]

(As I go through the backlog, I see this is quite similar to what @kakra proposed in #13 )