Comment 46 for bug 204133

Hi, Just to confirm Ago's statements:

> 1) The "linux" bug mentioned in comment #17 is relevant for low levels of dirty_ratio. The ntfs-3g patch will avoid lowering the dirty_ratio and will indirectly help (which is a subcase of #2 above).

Correct. The dirty ratios are at best a dirty hack, and when pushed to their limits, do show up some problems - which I don't think are appropriate to workaround in the kernel. The correct approach is to avoid the sysctl's on the dirty ratios and hit the crux of the problem and that is to make sure that ntfs-3g is flushing data using the O_SYNC open() flag rather than forcing it using some very aggressive vm tweaks.

> 2) There was some discussion on the performance / reliability of the loop device in write intensive set-ups. See for instance http://lkml.org/lkml/2008/1/9/50. Colin seems to like the dm-loop approach. I am not sure if there are data loss scenarios that could be improved upon by using dm-loop or whether it is mostly a performance issue. My guess is that dm-loop might help with point #1 in comment #31

I think that patching the loopback is more of a technical risk than using dm-loop. I think it's a case of getting Wubi working with dm-loop and comparing performance with the normal loopback and making a decision based in reliability and performance. As yet, I have no hard facts to make a decision either way on this. I suspect dm-loop will help with #1 in https://bugs.edge.launchpad.net/wubi/+bug/204133/comments/31 from my understanding of the code, but I have not verified this in practice.

> 3) It would be nice to be able to use the standard mount option name "-o sync" as opposed to have to create a new one for each filesystem "-o syncio". Not least because it will create a bit of special casing in other code (lupin/initramfs-tools). From a past discussion with Colin it emerged that the naming was to work around fuse -o sync handling.

Correct. For the -o sync fuse option to work, there needs to be considerable amount of effort required in honoring the -o sync flag in the kernel side of fuse and being passed down and handled in the user space side too. The simplest option was for ntfs-3g to pick up the -syncio option and handle it there rather than add generic -o sync support in fuse per se.

> 4) There is also a remount issue with loopdevices (see #201750). On top of that, there are separate remount issues for ntfs-3g (see #186117), even worse, it seems that remounting ntfs-3g ro/rw can produce data loss (https://bugs.edge.launchpad.net/wubi/+bug/186117/comments/10). Not sure if newer versions of fuse/ntfs-3g address this.

Not sure either.

> 5) Related to the above there are the shutdown issues mentioned by Colin in comment #19. I am not sure what is that state of that given A) the ntfs-3g patch and possibly B) dm-loop usage.

I suspect that the sync'ing of data with ntfs-3g will help considerably in ensuring that the data is being written back. My hope is that dm-loop will have less latency between writes to the loopback and data being written back than the normal loopback. It appears it should be better, but we need to test this hypothesis.

Colin