[squeak-dev] new VM appears not to be flushing

David T. Lewis lewis at mail.msen.com
Mon Jan 13 02:31:26 UTC 2020


A wise plumber once taught me that flushing harder is almost never
the right thing to do ;-)

On a Unix (OS X) VM, #flush calls fflush() in the C runtime library.
This flushes the stream data out of your program data space (the VM)
but it may or may not write it out to the storage medium.

In addition to #flush, we also have #sync which calls fsync(). This
is a lower level system call on Linux (and probably other unices such
as OS X), and it performs a "flush" out to the actual storage medium. 

You will definitely want to read the man pages (man 3 fflush, and
man 2 fsync) on whatever system you are using to get a better description
of the differences.

With respect to VM changes, there is very little chance that the
VM (FilePlugin actually) has changed recently. But is it certainly
possible that the compilers and runtime libraries have changed over
the last year or so, and it is possible that the actual runtime
behavior of fflush() will be different as a result. If so, I would
not regard that as a VM problem per se, it is really going be a
difference in the runtime environment.

As a point of comparison, I find that my CommandShell has accumulated
a few bugs over the years as a result of differences in the runtime
environments on Linux and other Unix systems. Some of these I have
addressed, and some I haven't. But it is not a defect in the VM, more
likely it is some poor assumptions in my original implementation that
became visible as the runtime C library changed.

HTH,
Dave


On Mon, Jan 13, 2020 at 01:15:15AM +0100, Levente Uzonyi 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
> >
> >

> 



More information about the Squeak-dev mailing list