> I think #sync is what I want since I want it to be safe from sudden power
outage, not just a process kill.

Wow, perhaps not, this is really hammering the HD, solid busy light, on an
SSD!

On Mon, Jan 13, 2020 at 10:56 PM Chris Muller <asqueaker at gmail.com> wrote:

> Oh, okay, #sync does what I *thought* #flush did.  I would never discover
> some of these things if you weren't so generous with your expertise,
> thanks.  I think #sync is what I want since I want it to be safe from
> sudden power outage, not just a process kill.
>
> I did try changing it to #sync, but it still failed the same.  I then went
> back and tried my #reopen a second time, this time it failed in the same
> way too!  So either it got lucky before, or I err'd in my testing somehow,
> but I'm actually glad that it seems to be failing consistently now.
>
> There's definitely something different with the new VM, but it's not
> flush.  Sorry for the false alarm.  I'll have to keep digging.
>
>  - Chris
>
> On Mon, Jan 13, 2020 at 4:39 PM Levente Uzonyi <leves at caesar.elte.hu>
> wrote:
>
>> Hi Chris,
>>
>> #flush calls fflush(), #sync calls #fflush() and then #fsync().
>> The former does not write data to disk, the latter does. And the latter
>> is
>> obviously a lot slower. If that explanation is not clear, this might be
>> better: https://stackoverflow.com/a/2340641
>>
>> On Mon, 13 Jan 2020, Chris Muller wrote:
>>
>> > The test case proves that it does.
>>
>> Can you give us a small snippet which reproduces the bug and can be
>> executed in a Trunk image?
>>
>> >
>> > The comment of the method is,
>> >
>> >     "When writing, flush the current buffer out to disk."
>>
>> That comment is wrong. That might have been true 21 years ago, even
>> though that's not very likely either.
>> The comment on StandardFileStream >> #flush is correct, but could be more
>> verbose: "Flush pending changes".
>>
>>
>> Levente
>>
>> >
>> > I know what filesystem I deploy to, but Squeak appears to be silently
>> ignoring this (rather important) expectation about #flush, that its own
>> > comment presents.
>> >
>> >   - Chris
>> >
>> >
>> >
>> > On Sun, Jan 12, 2020 at 6:15 PM Levente Uzonyi <leves at caesar.elte.hu>
>> wrote:
>> >       Hi Chris,
>> >
>> >       Do you expect #flush to write the changes to disk?
>> >
>> >       Levente
>> >
>> >       On Sun, 12 Jan 2020, Chris Muller wrote:
>> >
>> >       > Magma has been stable in 5.2 for a long time under an older VM,
>> all tests pass.  But by changing ONLY the VM (not the image) to the
>> >       new release-candidate, it fails the forward-recovery test.  This
>> test tests the scenario of a
>> >       > server failure during mid-write.  Unless I change
>> StandardFileStream>>#flush as in Files-cmm.182, the recovery data which
>> Magma
>> >       relies on #flush to ensure is preserved is, in fact, not
>> preserved.  It appears to be a breakage
>> >       > of the contract which causes the test to fail.  This
>> functionality is important to avoid corrupting databases.
>> >       > I saw a discussion on the Cuis list in which someone was
>> asserting that flush is no longer necessary(!!), and made a vague reference
>> >       to a "thread on squeak-dev" which I never found.
>> >       >
>> >       > I hope this is just an oversight, otherwise I'll have to rely
>> something like Files-cmm.182, which is half the speed of the old
>> >       #flush.
>> >       >
>> >       > Best,
>> >       >   Chris
>> >       >
>> >       >
>> >
>> >
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200113/0946de22/attachment.html>