4 ms·
The problem is that fsync() runs outside of the control of the program. There's no way for an application to start a transaction, perform steps x, y, and z, and
by Sanddancer 11y ago
The problem is that fsync() runs outside of the control of the program. There's no way for an application to start a transaction, perform steps x, y, and z, and then end a transaction, rolling back to before step x if there are any failures. For example, suppose you're rotating a an audit log file at the same moment your backup program is running. Your backup program reads the directory, and at that same moment, your rotate script had renamed the file, but had created the new file, but data hadn't been written to the file yet. What does the backup program see? does it see the old file you just renamed? Does it see the new zero-length file? Your backup now has an indeterminable state, and potentially lost data, because the backup received a consistent view of the overall data. Were there a way of creating a transaction, the second program looking at the same data would either see the old file, or would see the new file and the rotated file. This is where a transactional file system would be of great benefit, because it limits the amount of indeterminate state to a very minimum, even while multiple programs are operating on the same file.
- frutiger 11y agoRealistically, backups need to be based on atomic snapshots, like `zfs`.
- Sanddancer 11y agoYep. I'll admit my example was a bit convoluted, but I was trying to show a way in which common tasks can race and create undesirable situations. ZFS snapshots would definitely make things quite a bit more predictable.