Ago wrote:
Good questions. There are in fact 2 separate issues.
- Hosted filesystem corruption (ext3). When Ext3 writes the journal, the data
does not end up on the HD but gets handled by ntfs, which in turns may or may not write the data to the HD. So if you hard reboot, data loss in the hosting filesystem may cause journal corruption of the hosted filesystem, which makes recovery quite challenging.
This is I think what I've been noticing as well in a similar situation. The one time I tried to recover, fsck _completely_ horked the ext3 fs.
This is not an ntfs/ext3 specific issue, you would
have that in any nested filesystem configuration (or at least this is my understanding). What we have done was to tweak sysctl dirty settings, so that dirty pages are flushed to disk as often as possible.
This was also my first thought. The down side, is that in my usage scenario, the fs would be typically on a usb-flash-stick, and it seems like an undesirable thing to be writing to it as often as possible, rather than periodically.
Question- are these sysctl settings controlling the writes from the hosted-fs->host-fs, or from the host-fs->disk, or both?
That seems to have done
the trick. Since we did that, I cannot recall any complaint due to ext3 data loss, but of course that does not eliminate the issue.
On top of that we cannot hibernate/suspend. Suspend-to-ram is a problem because of the ordering in which userspace processes are terminated/resumed which becomes an issue if you use a userspace filesystem (if the loopfile is hosted on vfat, suspend works fine). With hibernation you also have to handle the issue of having swap on a file.
This sounds like it could be fixed with smarter ordering. Do you foresee that, or is it for some reason a more-or-less unfixable problem?
My take on all this is that Wubi is a "short term" installation. It's good
...
It's a trade-off.
That's engineering ;)
thx...
-dmc