Committing changes (deletes) on unmount / termination

[tvogel]

I am using TigrisFS to make backups using BorgBackup to a Tigris S3 Bucket. This works fine but I am encountering spurious problems that sometimes, BorgBackup's removal of its lock-file in the end of a backup run (purging old archives in my specific case) sometimes gets lost before unmounting. Because of the orphaned lock-file, subsequent backup runs fail to start.

I am running this from a fly.io Dockerfile based VM that only runs for the duration of the backup.

1. VM starts up
2. Script mounts TigrisFS for the BorgBackup repository (and another TigrisFS for the data to be backed up)
3. Script runs BorgBackup to backup and prune archives, each run creates a lock-dir with a lock-file and removes them after the operation.
4. Script unmounts TigrisFS using fusermount3 -u (waiting for its completion)
5. Script terminates
6. fly.io shuts down the VM on exit of the main Dockerfile CMD.

Now, I am wondering: Do I have to expect that some background operation needs to run past the exit of fusermount3 -u in order to fully commit last-second changes (like deleting the lock-file) to Tigris S3? If so, what should my script wait for?

Context: See https://github.com/SupaAutoFly/S3BorgBackup/blob/037b77f6f73e831c33df0c0b7a5438bc02da9c47/scripts/backup.py

[tvogel]

OK, it seems that even after fusermount3 -u has terminated, there is still a tigrisfs process alive, finishing up pending operations. I don't particularly like that behavior but I can work around it, waiting for the tigrisfs process for the respective mount-point to terminate before I shut down the machine.

[ovaistariq]

Hi @tvogel, fusermount3 will terminate once the mountpoint is detached from the namespace and disappears from userland. It doesn't necessarily wait for tigrisfs to complete flushing of data. This is probably why you see the tigrisfs process linger for sometime.