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

[Andres Valloud]

I think the journaling filesystem concept is a distraction here.  The 
reality is that unless you:

a) never make a single mistake via an FFI (IME this is already almost 
impossible, witness e.g. the efforts to call POSIX / SUS functions via 
the FFI mechanism),

b) have a perfect virtual machine with exactly zero bugs,

c) and otherwise manage to never, ever freeze your system by making less 
than perfect changes,

then sooner or later you will need a way to make sure what was just 
written to the recovery log of choice is actually written before continuing.

FYI: I had to implement forceful disk flushing for virtual machine logs 
because when the VM crashes whatever is pending to be written gets lost 
--- typically this is the debug log, so it's counterproductive to lose 
such recovery records only when you need them.  I had to do the same for 
Assessments, the testing tool I wrote: that's why there's a record 
keeping policy that opens then closes the log file every time something 
it written to it.  Otherwise, if you happen to be running the virtual 
machine tests, and said tests aggressively try to crash the system 
(that's the point, btw), and said tests succeed in bringing them system 
down, then you have a problem: exactly which test managed to do that?

On 9/16/19 09:13, Juan Vuletich via Cuis-dev wrote:
> On 8/29/2019 1:16 AM, Phil B via Cuis-dev wrote:
>> Changeset attached.  I was reading a thread on squeak-dev and this 
>> subject came up re: the current implementation of #forceChangesToDisk 
>> being fairly pointless (i.e. modern OSes will see what's being done 
>> and effectively ignore the attempt to force the write by closing and 
>> re-opening)  But let's say that isn't the case: it's not the 90's 
>> anymore and we're not running Win 3.x/9x or OS 7-9 where a VM crash 
>> could and would bring down your system.   On top of that, the vast 
>> majority of us are running with journaling filesystems these days so 
>> even in a worst-case scenario, the old behavior adds no value that I 
>> can see. (i.e. if the write can't be ensured/recovered at the OS 
>> level, it's unlikely that the old code is going to do anything to help)
> 
> Thanks!
> 
> Cheers,
>