[Cuis-dev] [Integrated] Re: #forceChangesToDisk

[Phil B]

Andres,

On Mon, Sep 16, 2019 at 7:24 PM Andres Valloud via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> Phil,
>
> Note well: I didn't question the code.
>
>
I didn't take your comment as an attack on the code (besides all I did was
delete a couple of lines and it's a pretty trivial method anyway)


> On 9/16/19 13:06, Phil B wrote:
> > Andres,
> >
> > I disagree with your assertion: journaling is a major (dominant?)
> > contributing factor to applications no longer needing to be so paranoid
> > about data getting written.  Your scenarios are valid (I run into all of
> > them regularly)
>
> That's the point, really: journaling won't save you (because as you say,
> the scenarios are valid and you experience them regularly), so let's not
> use journaling to justify changes to 'forceChangesToDisk' methods.
>
> Nothing's stopping anyone from running Cuis on a FAT formatted USB
> drive, i.e. without journaling (that I know of).  If just flushing is
> supported by journaling, does the absence of journaling invalidate the
> argument?  I don't think so --- then let's not mention journaling :).
>
>
I was trying to (apparently unsuccessfully) use journaling as a
shorthand[1] for the many ways in which systems are different today than
when that method was originally implemented.  Fine, let's forget journaling.

It's the flushing of the buffer (which is still there) that is the
important bit.  That signals to the OS 'OK, make sure this data written'.
The rest of the code was a hack to basically try to force the OS to do the
write immediately.  This used to work[2], but per the conversation on
squeak-dev, no longer does.  My position is that even if it still does work
in some cases, it's a hack that was based on a set of assumptions that are
no longer valid today.

When I say that I experience the scenarios you describe, I absolutely
have... but that has nothing to do with whether or not the data gets
written.  It is because the data was flushed and the OS made sure the write
happened, not the closing and reopening of the file, regardless of whether
or not the application crashed a few milliseconds later.  It's a question
of whether or not you can trust flush to get the data from the application
to the OS and for the OS to do it's job.  My contention is that on current
systems, you can trust that things will happen as they are supposed to (in
large part because it's very difficult for even a badly designed/behaved
program to take down the OS with it these days... unless it's malicious)

Is it possible to do a better job at data integrity than what the OS
provides for us?  Absolutely.  Is closing and reopening a file the way to
do it today?  Absolutely not.

[1] i.e. that even in many catastrophic failure modes, you can be confident
that if it was possible to write your data, that data got written...
eventually.

[2] And be necessary given how crash-happy systems were back in the day.

Andres.
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20190916/39efb646/attachment-0001.htm>