RFE: Better lock handling

[kakra]

I'm not sure if the current locking implementation with leases is the right thing to do. Shake should acquire an unbreakable file lock because otherwise it may mess up with your files in case of a timeout and you cannot let it run unattended.

The number one priority of a defragger should be safety of the users data, and this is currently not implemented at a convenient level. Other defraggers like btrfs-defrag and xfs_fsr use unbreakable locks to ensure the files don't get messed up.

If some other application has to access the file, it has to wait. The current implementation allows the other application to break the lock, and what that application find is a broken, empty, or partial file. At least during rewrite phase the lock has to be unbreakable.

[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 :warning:
• 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) :warning:
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 )