<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div> - Chris</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 13, 2020 at 4:39 PM Levente Uzonyi <<a href="mailto:leves@caesar.elte.hu" target="_blank">leves@caesar.elte.hu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Chris,<br>
<br>
#flush calls fflush(), #sync calls #fflush() and then #fsync().<br>
The former does not write data to disk, the latter does. And the latter is <br>
obviously a lot slower. If that explanation is not clear, this might be <br>
better: <a href="https://stackoverflow.com/a/2340641" rel="noreferrer" target="_blank">https://stackoverflow.com/a/2340641</a><br>
<br>
On Mon, 13 Jan 2020, Chris Muller wrote:<br>
<br>
> The test case proves that it does.<br>
<br>
Can you give us a small snippet which reproduces the bug and can be <br>
executed in a Trunk image?<br>
<br>
> <br>
> The comment of the method is, <br>
> <br>
>     "When writing, flush the current buffer out to disk." <br>
<br>
That comment is wrong. That might have been true 21 years ago, even <br>
though that's not very likely either.<br>
The comment on StandardFileStream >> #flush is correct, but could be more <br>
verbose: "Flush pending changes".<br>
<br>
<br>
Levente<br>
<br>
> <br>
> I know what filesystem I deploy to, but Squeak appears to be silently ignoring this (rather important) expectation about #flush, that its own<br>
> comment presents.<br>
> <br>
>   - Chris<br>
> <br>
> <br>
> <br>
> On Sun, Jan 12, 2020 at 6:15 PM Levente Uzonyi <<a href="mailto:leves@caesar.elte.hu" target="_blank">leves@caesar.elte.hu</a>> wrote:<br>
>       Hi Chris,<br>
><br>
>       Do you expect #flush to write the changes to disk?<br>
><br>
>       Levente<br>
><br>
>       On Sun, 12 Jan 2020, Chris Muller wrote:<br>
><br>
>       > 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<br>
>       new release-candidate, it fails the forward-recovery test.  This test tests the scenario of a<br>
>       > server failure during mid-write.  Unless I change StandardFileStream>>#flush as in Files-cmm.182, the recovery data which Magma<br>
>       relies on #flush to ensure is preserved is, in fact, not preserved.  It appears to be a breakage<br>
>       > of the contract which causes the test to fail.  This functionality is important to avoid corrupting databases.<br>
>       > I saw a discussion on the Cuis list in which someone was asserting that flush is no longer necessary(!!), and made a vague reference<br>
>       to a "thread on squeak-dev" which I never found.<br>
>       ><br>
>       > 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<br>
>       #flush.<br>
>       ><br>
>       > Best,<br>
>       >   Chris<br>
>       ><br>
>       ><br>
> <br>
> <br>
><br>
</blockquote></div>