Sync before umount filesystems

[majst01]

Description

We observe read-only filesystems after installation finished and kexec into the os on certain newer machines.
This might be because of faster hardware, try to avoid this by flushing fs content before umounting.

Related: #186
Eventually replaces: #185

Used AI-Tools ✨

• none used for generation

[GeertJohan]

I no longer think a sync before unmount is the correct approach;

• After a sync but before unmount, an new write may be executed against an open fd, making the sync useless.
• Any open fd should simply be closed when we perform the unmount, sync (and/or a unmount retry loop) are workarounds for a different issue.

I think I identified the original cause and have updated #186, and have proposes new PR (#188) with stricter unmount.

[majst01]

I no longer think a sync before unmount is the correct approach;

• After a sync but before unmount, an new write may be executed against an open fd, making the sync useless.
• Any open fd should simply be closed when we perform the unmount, sync (and/or a unmount retry loop) are workarounds for a different issue.

I think I identified the original cause and have updated #186, and have proposes new PR (#188) with stricter unmount.

But when umount is called in filesystem.go, there should be no additional writes happen.
As i can quite easily reproduce this in one of our environments, i will try this and yours and we will see.

[GeertJohan]

But when umount is called in filesystem.go, there should be no additional writes happen.

Correct, and then sync will run as part of that unmount syscall, but only after linux confirmed there are no open file pointers. It's a more consistent sync and was only broken because there actually was an open file pointer which caused the EBUSY (which was ignored by metal-hammer; only logged).

[majst01]

closed in favour of #190