It's certainly do-able; we had a system like this at Interval. Basically write an image to a suitably chosen name, check if it was ok (which could involve a lot of work if you want to be paranoid) and if so rename (and check the rename worked!) and quit. Craig might possibly have the code around? I certainly don't.
On 2020-01-29, at 12:10 PM, Tony Garnock-Jones tonyg@leastfixedpoint.com wrote:
That sounds like a great idea.
On configurations where overwrite-by-rename is a problem, perhaps an alternate of "copy the existing image to a *.bak file" would work?
Perhaps the image save primitive could respond to a VM command-line switch (or in-image VM parameter?) selecting among three behaviours:
- The current overwrite-in-place, risk-of-corruption behaviour
- Overwrite-by-rename if possible
- Make backup copy before overwrite-in-place
Regards, Tony
On 1/29/20 6:00 PM, Thiede, Christoph wrote:
Hi all,
some months ago, I corrupted my image by accidentally shutting down the host system while saving the image file (many of my images are > 500 MB, so this can take a few seconds even on an SSD). The same can happen due to various other IO/connection issues, so here's an idea: Couldn't we always use overwrite-by-rename when saving the image file? I. e., first the image into a new temporary file and, after saving has completed, replace the original file with that temp file (via mv)? This would ensure the image file's integrity.
A possible disadvantage, though, would be that some filesystems, such as NTFS, associate meta-information with the file identity, which changes when using the overwrite-by-rename approach. Also, technologies such as FileSystemWatcher would be confused for the same reason. However, afaik overwrite-by-rename is a quite common approach, in primary for big and sensitive files.
However, what are your opinions about this topic? :-)
Best,
Christoph
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Living dead