<div dir="ltr"><div dir="ltr">Andres,<div><br></div><div>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) but believe the new method will prove to be just as reliable as the old one on modern systems without the overhead it incurred. (i.e. closing and opening the file was definitely occurring at the image/VM level, doubtful at the OS level, and even if it were it is arguable that the value it was providing beyond what the OS does is minimal)  Can you provide a reproducible non-pathological example where the new code fails but the old code doesn't?[1]  The point of the change was that the old code added no value on modern systems, not that ensuring that data being written isn't important.</div><div><br></div><div>[1] I really don't believe there is one or I wouldn't have submitted the changeset.</div></div><div><div><br></div><div>Thanks,</div><div>Phil</div><div><br><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 16, 2019 at 12:21 PM Andres Valloud via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">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">I think the journaling filesystem concept is a distraction here.  The <br>
reality is that unless you:<br>
<br>
a) never make a single mistake via an FFI (IME this is already almost <br>
impossible, witness e.g. the efforts to call POSIX / SUS functions via <br>
the FFI mechanism),<br>
<br>
b) have a perfect virtual machine with exactly zero bugs,<br>
<br>
c) and otherwise manage to never, ever freeze your system by making less <br>
than perfect changes,<br>
<br>
then sooner or later you will need a way to make sure what was just <br>
written to the recovery log of choice is actually written before continuing.<br>
<br>
FYI: I had to implement forceful disk flushing for virtual machine logs <br>
because when the VM crashes whatever is pending to be written gets lost <br>
--- typically this is the debug log, so it's counterproductive to lose <br>
such recovery records only when you need them.  I had to do the same for <br>
Assessments, the testing tool I wrote: that's why there's a record <br>
keeping policy that opens then closes the log file every time something <br>
it written to it.  Otherwise, if you happen to be running the virtual <br>
machine tests, and said tests aggressively try to crash the system <br>
(that's the point, btw), and said tests succeed in bringing them system <br>
down, then you have a problem: exactly which test managed to do that?<br>
<br>
On 9/16/19 09:13, Juan Vuletich via Cuis-dev wrote:<br>
> On 8/29/2019 1:16 AM, Phil B via Cuis-dev wrote:<br>
>> Changeset attached.  I was reading a thread on squeak-dev and this <br>
>> subject came up re: the current implementation of #forceChangesToDisk <br>
>> being fairly pointless (i.e. modern OSes will see what's being done <br>
>> and effectively ignore the attempt to force the write by closing and <br>
>> re-opening)  But let's say that isn't the case: it's not the 90's <br>
>> anymore and we're not running Win 3.x/9x or OS 7-9 where a VM crash <br>
>> could and would bring down your system.   On top of that, the vast <br>
>> majority of us are running with journaling filesystems these days so <br>
>> even in a worst-case scenario, the old behavior adds no value that I <br>
>> can see. (i.e. if the write can't be ensured/recovered at the OS <br>
>> level, it's unlikely that the old code is going to do anything to help)<br>
> <br>
> Thanks!<br>
> <br>
> Cheers,<br>
> <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></div></div></div>