[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
|