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