Hi, On 01/15/2012 05:26 AM, ext Pavel Řezníček wrote:
But What I noticed during my experiments is that the loop mount support is somehow bad. When Easy Debian was mounted from an image file, as I started an I/O-intensive or CPU-intensive task such as copying the contents of the image to the card,
Loop images aren't a good idea for several reasons. * Using them can take a lot more (kernel) memory than just chrooting to a directory with debian stuff If device runs completely out of memory without it being cause by user-space processes that could be killed, or it requiring also SW watchdog protected things (like X server to be killed), device will be rebooted.
my device almost always ended up in a shutdown or reboot and huge filesystem corruption inside the image file.
* That's fairly obvious. Journaling file system guarantee only consistency of the file system metadata, not file contents, and you're having two such things on top of each other. Therefore meta data of the file system within the loop image isn't protected and gets corrupted if you've been doing file system modifications inside the loop image just before reboot. For such modification not to be corrupted on reboot, they would need to have been first synched to the image itself by the FS used inside the image, then synched to the real media by the file system on where the loop image itself resides.
Yes, even if I ran /rsync/ with the highest nice level. This is something for the power kernel developers to consider and think about. (But keep in mind I work with the stock kernel.)
- Eero _______________________________________________ maemo-users mailing list maemo-users@xxxxxxxxx https://lists.maemo.org/mailman/listinfo/maemo-users
