Re: Troubles with chrooted Debian

Dne 5.1.2012 01:41, Paul Hartman napsal(a):
> On 1/4/2012 4:32 PM, Pavel Řezníček wrote:
>> I’d though appreciate if you send me the precompiled kernel module
>> (along with some instructions or web resources how to install it).
> It is attached inside a ZIP file. This module is only for use with stock
> kernel, not power kernel!
>
> …
>
> If your card was affected by this bug, hopefully using this module will
> now allow your card to work with no more corruption (after reformat).
Great! Now, after the installation of your fixed kernel module, I run
Easy Debian without bigger problems! Thank you so much for your help,
/it really works!/
Even when the N900 gets switched off or reboots accidentally while Easy
Debian’s filesystem on the card is mounted, the damage to it is always
so small that it’s fairly repairable, almost with no harm to the data.
Even my TDK card behaves nicely.
I have the Lazarus IDE compiled and working now :-) I’ve started to port
my older commercial project to Maemo recently :-)
For those interested: It’s called MiniMU and should serve as a task
tracking and management on-line binary database client for lift
servicemen (and eventually grow into a multi-purpose database
application). I have developed it for my former employer and nowadays I
continue on the same project on my own, expecting him to buy the new
part of the work.

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, my device almost always ended up in a
shutdown or reboot and huge filesystem corruption inside the image file.
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.)

>> Thank you again for your guidance.
> You are welcome, I hope it will solve your problem!
>
> Thanks,
> Paul
Yes, it really solved my problem! Thank God for such experienced and
helpful people like you.

Pavel

--
function Podpis(): String;
begin
Jméno('Pavel Řezníček');
Bydliště('Borová 18', '312 00', 'Plzeň');
Pracoviště('Korandův sbor', 'Anglické nábřeží 13', '301 00', 'Plzeň');
Result := 'vývojář a správce sítě';
end;

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

Hello Eero,

thank you for your response!
So it seems that the default way Easy Debian is installed isn't the best one chosen, at least not the most reliable.
It’s wonderful how complex problematics lie under the “simple” file image mounting and writing to it.
Thanks for the detailed clarification.
It’s really very probable that I used to run into entire memory consumptions and such critical situations.
So maybe it isn't anybody’s fault or responsibility, especially not the kernel developers’. A safe solution for such an intensive image file usage might be pretty complex.

Have a nice winter day. Regards for everybody on the mailing list.

Pavel