<div dir="ltr"><div dir="ltr">Andres,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 16, 2019 at 7:24 PM Andres Valloud via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</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">Phil,<br>
<br>
Note well: I didn't question the code.<br>
<br></blockquote><div><br></div><div>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) </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On 9/16/19 13:06, Phil B wrote:<br>
> Andres,<br>
> <br>
> I disagree with your assertion: journaling is a major (dominant?) <br>
> contributing factor to applications no longer needing to be so paranoid <br>
> about data getting written.  Your scenarios are valid (I run into all of <br>
> them regularly)<br>
<br>
That's the point, really: journaling won't save you (because as you say, <br>
the scenarios are valid and you experience them regularly), so let's not <br>
use journaling to justify changes to 'forceChangesToDisk' methods.<br>
<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Nothing's stopping anyone from running Cuis on a FAT formatted USB <br>
drive, i.e. without journaling (that I know of).  If just flushing is <br>
supported by journaling, does the absence of journaling invalidate the <br>
argument?  I don't think so --- then let's not mention journaling :).<br>
<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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)</div><div><br></div><div>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.</div><div><br></div><div>[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.</div><div><br></div><div>[2] And be necessary given how crash-happy systems were back in the day.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Andres.<br>
-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote></div></div>