Comment 52 for bug 204133

Hi Szabolcs,

The reason for the O_SYNC option in the open on the NTFS device was mainly to ensure Wubi was writing data back to NTFS. Wubi relies on a loopback'd file system in a file in the ntfs fileystem, and hence there was a lot of latency between a write to the loopback, down through the ntfs filesystem via fuse. We were seeing problems with power-outages causing systems to become unbootable due to the write-back cached data latencies. One hacky approach was to tweak the vm settings to force writebacks as soon as possible to avoid blocks hanging around in the cache - this was a hack and not an elegant solution as it applies to all file systems across the board. Hence I added the O_SYNC option to ntfs-3g avoid this hack.

Basically we ultimately need a method of ensuring ntfs data and metadata is sync'd to disk asap to keep Wubi as robust as possible. As for performance penalty, I have also benchmarked the SYNC mode of operation and it is inline with the figure your report. This is probably OK for Wubi since most of the I/O operations are read and not writes, and I suspect robustness is more important than speed - but it will probably be an choice that the Wubi user can make.

Colin.