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

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


Hi Dave,


> On Jan 30, 2020, at 5:18 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> My suggestion is to just try some ideas in your own image and see
> if it's something you want to live with. The intentions are good but
> I have a feeling that this is the kind of thing where the inintended
> side effects are worse than the problem to be solved.

+1

> 
> In my own experience, I have encountered an IO error while saving
> the image several times over the years. In every case, the cause has
> been a file system full condition. A solution that uses more disc
> space would not have been helpful.

Good point.  The snapshot primitive *could* make a conservative estimate of the file size needed (easy; it knows how big the heap is), create a file, write that many zeros (only way to actually commit the disc space), and then overwrite with the real data, but that’s twice the disc traffic.

> 
> Tim mentions using OSProcess, so you can try something based on
> "UnixProcess saveImageInBackground" if you want.
> 
> Dave
> 
>> On Thu, Jan 30, 2020 at 12:13:27PM +0000, Thiede, Christoph 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?
>> 
>> 
>> <http://www.hpi.de/>
>> 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?
>> 
>> 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 :)
>> 
>> +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?
>> 
>> 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.
>> 
>> 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."
>> 
>> 
>> 
>> 
> 
>> 
> 
> 


More information about the Squeak-dev mailing list