> "Magnus Hagander" <mha@sollentuna.net> writes:
>> My results are:
>> Fisrt, baseline:
>> * Linux, with fsync (default), write-cache disabled: no data corruption
>> * Linux, with fsync (default), write-cache enabled: usually no data
>> corruption, but two runs which had
>
> That makes sense.
>
>> * Win32, with fsync, write-cache disabled: no data corruption
>> * Win32, with fsync, write-cache enabled: no data corruption
>> * Win32, with osync, write cache disabled: no data corruption
>> * Win32, with osync, write cache enabled: no data corruption. Once I
>> got:
>> 2005-02-24 12:19:54 LOG: could not open file "C:/Program
>> Files/PostgreSQL/8.0/data/pg_xlog/000000010000000000000010" (log file 0,
>> segment 16): No such file or directory
>> but the data in the database was consistent.
>
> It disturbs me that you couldn't produce data corruption in the cases
> where it theoretically should occur. Seems like this is an indication
> that your test was insufficiently severe, or that there is something
> going on we don't understand.
>
I was thinking about that. A few years back, Microsoft had some serious
issues with write caching drives. They were taken to task for losing data
if Windows shut down too fast, especially on drives with a large cache.
MS is big enough and bad enough to get all the info they need from the
various drive makers to know how to handle write cache flushing. Even the
stuff that isn't documented.
If anyone has a very good debugger and/or emulator or even a logic
analyzer, it would be interesting to see if MS sends commands to the
drives after a disk write or a set of disk writes.
Also, I would like to see this test performed on NTFS and FAT32, and see
if you are more likely to lose data on FAT32.