In 2.4.20-pre5 an optimisation was made to the ext3 fsync function which can very easily cause file data corruption at unmount time. This was first reported by Nick Piggin on November 29th (one day after 2.4.20 was released, and three months after the bug was merged. Unfortunate timing) This only affects filesystems which were mounted with the `data=journal' option. Or files which are operating under `chattr -j'. So most people are unaffected. The problem is not present in 2.5 kernels. The symptoms are that any file data which was written within the thirty seconds prior to the unmount may not make it to disk. A workaround is to run `sync' before unmounting. The optimisation was intended to avoid writing out and waiting on the inode's buffers when the subsequent commit would do that anyway. This optimisation was applied to both data=journal and data=ordered modes. But it is only valid for data=ordered mode. In data=journal mode the data is left dirty in memory and the unmount will silently discard it. The fix is to only apply the optimisation to inodes which are operating under data=ordered. This patch fixes the data loss which can occur when unmounting a data=journal ext3 filesystem. http://www.redhat.com/mailing-lists/ext3-users/msg08798.html
That patch seems to not work correctly...Btw complete patch is here: http://kerneltrap.org/node.php?id=519#patch :)) Que
Hmm... I can drop this into lolo-sources if I need to. Double check that it is needed against 2.4.20 final, and that the patch in the later article is correct for me, thanks.
done and done
