Ago wrote:
Good questions. There are in fact 2 separate issues.
2) 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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
