[squeak-dev] new VM appears not to be flushing
leves at caesar.elte.hu
Mon Jan 13 22:38:57 UTC 2020
#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
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".
> 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?
> 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
> > Best,
> > Chris
More information about the Squeak-dev