[squeak-dev] Image damaged due to IO error while saving

Eliot Miranda eliot.miranda at gmail.com
Thu Jan 30 14:14:30 UTC 2020


Hi Christoph,

> On Jan 30, 2020, at 4:13 AM, Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:
> 
> 
> Hi all!
> 
> 
> 
> > On configurations where overwrite-by-rename is a problem, perhaps an alternate of "copy the existing image to a *.bak file" would work?
> 
> 
> Compared to overwrite-by-rename, this proposal would double the storage effort. Provided that I understand you correctly, -1 :-)
> 
> > On configurations where overwrite-by-rename is a problem, perhaps an alternate of "copy the existing image to a *.bak file" would work?

If you want a backup, even temporarily, then you can’t avoid needing twice the file storage while the new snapshot is being written.  So careful what you wish for.  All implementations have this as a consequence, by definition.

> What would you like to do with this backup file? Keep them permanently? As we speak about hundreds-of-megabytes file sizes, I think this could be quite storage extensive ... Also, it messes up your image folder. We already have two files for each image: .image and .changes. No need for even more files, imho. But there may always be some special application areas, of course :)

Well, if it stays around then it gets replaced on every save.  So one only has one copy per image.  One presumably would never rename the backup to save it when creating the next backup.  So in fact the operation is

- if saving to an existing file
    - delete the backup foo.imagebak if it exists
    - rename foo.image to foo.imagebak
    - save the image
    - optionally validate the new image
    - optionally delete the backup

> +1 for making a preference for it :-)
> However, my personal flavor would be to rule this behavior via the Squeak.ini file (not sure what's the equivalent on other host platforms), so I would prefer to store this preference image-invariant.
> 
> VM support: What would be the pros and cons of implementing this in the VM?
> First, I don't know whether we already support a way to read the Squeak.ini file from within the image (see above)?
> Second, I *could* imagine (though this is spoken hypothetically) that certain host systems might provide convenient ways for implementing overwrite-by-rename. See my initial mail for my worries about a naive implementation. Again, wouldn't this be an argument for implementing this rather at VM side?

Good questions.  I think implementing image side is better.  The snapshot primitive is separate from the quit primitive, so if the snapshot primitive succeeds there is time for the image to eg run validation and/or delete the backup before quitting.

This seems to me relayed to the other snapshot bug, which is that we GC in the snapshot primitive. This is completely wrong because it elides finalization actions.  Instead we should do a full GC in the image *before* doing the snapshot, allow any finalization actions to complete and then do the snapshot.  VW does this correctly.

> Ad validation: Sounds interesting! How high would be the effort for that? Could you do this from within the VM (it's also a question of performance, I guess)? Wouldn't this double the store time? Maybe it would be a good idea to have a second (VM) preference for toggling validation.

Validation could (and IMO /should/) be fine via the new image leak checker.  This is a cut down vm that only loads an image and applies the leak checker before quitting.  To make this runnable from the image eg vis OSProcess.  That makes this an optional project because OSProcess is not in the base image.

> 
> Best,
> Christoph
> Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von tim Rowledge <tim at rowledge.org>
> Gesendet: Mittwoch, 29. Januar 2020 22:05:07
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] Image damaged due to IO error while saving
>  
> 
> 
> > On 2020-01-29, at 12:24 PM, Tony Garnock-Jones <tonyg at leastfixedpoint.com> wrote:
> > 
> > Oh, I see, so it's probably something that can be arranged entirely
> > image-side, no VM support needed. Right?
> 
> Pretty sure it could be done without VM support, yes. One might even use the OSProcess forking trick to do it, I think.
> 
> > ... it'd be a Preference, I suppose?
> Yet another ...
> 
> 
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> "How many Kdatlyno does it take to change a lightbulb?” 
> "None. It sounds perfectly OK to them."
> 
> 
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200130/d0831919/attachment.html>


More information about the Squeak-dev mailing list