Am Montag, 10. Januar 2011, 19:16:00 schrieb Andrew:
> 10.01.2011 20:04, KP Kirchdoerfer пишет:
> > Am Donnerstag, 6. Januar 2011, 15:44:37 schrieb KP Kirchdoerfer:
> >> Am Donnerstag, 6. Januar 2011, 15:06:42 schrieb Andrew:
> >>> 06.01.2011 15:56, KP Kirchdoerfer пишет:
> >>>> Hi;
> >>>> 
> >>>> this is from an old mail, but I tested today what happens if
> >>>> Bering-uClibc3 runs out of memory and what happens on Bering-uClibc4
> >>>> box.
> >>>> 
> >>>> Am Samstag, 12. Juni 2010, 20:17:49 schrieb Andrew:
> >>>>> Hi.
> >>>>> I just finished migration from compressed minix initrd to initramfs
> >>>>> that uses compressed as cpio.gz archive with files.
> >>>>> I'm done this due to several reasons:
> >>>>> 1) Support for multiple initrd files (so, it'll be possible to split
> >>>>> initrd module packages);
> >>>>> 2) It's much easier to repack .cpio archive, and minix driver can be
> >>>>> excluded from kernels (both LEAF and host)
> >>>>> 
> >>>>> Due to migration I omitted diverting of rootfs into separate ramdisk
> >>>>> - IMHO it's really unuseful in that case; rootfs with it's default
> >>>>> size will take up to half of available RAM during filling - so it'll
> >>>>> be enough big, and it'll .never consume all available memory. (I
> >>>>> check this, it's working)
> >>>>> 
> >>>>> One of it's cons that I found - there is no initramfs usage
> >>>>> statistics in output of 'df'.
> >>>> 
> >>>> I simulated running out of space with dd
> >>>> dd if=/dev/zero of=output.file bs=1024 count=1024
> >>>> filling up the memory to the max.
> >>>> 
> >>>> If a Bering-uClibc3 box runs out of memory the dd command fails with
> >>>> the message "no disk on space" and refused to generate the last MB. On
> >>>> a Bering-uClibc4 it starts to kill processes:
> >>>> [36521.153494] Out of memory: kill process 2809 (mini_httpd) score 87
> >>>> or a child
> >>>> [36521.160859] Killed process 2809 (mini_httpd) vsz:696kB,
> >>>> anon-rss:88kB, file- rss:180kB
> >>>> [36521.190261] Out of memory: kill process 2228 (dnsmasq) score 85 or
> >>>> a child [36521.197453] Killed process 2228 (dnsmasq) vsz:680kB,
> >>>> anon-rss:80kB, file- rss:256kB
> >>>> [36521.219629] Out of memory: kill process 2897 (aiccu) score 37 or a
> >>>> child [36521.226586] Killed process 2897 (aiccu) vsz:4796kB,
> >>>> anon-rss:120kB, file- rss:264kB
> >>>> 
> >>>> This is a serious pb and it may happen that a remote box is
> >>>> unavailable even for login via ssh, so you can't just reboot it.
> >>>> 
> >>>> Something I've overlooked?
> >>>> kp
> >>> 
> >>> Hmm, it looks like initramfs behavior was changed from 2.6.32 kernel,
> >>> and now it hasn't limit in half of available memory.
> >>> We can switch back to rootfs on tmpfs, this will require some init
> >>> scripts modification.
> >> 
> >> I found a text which describes the pb's I found (don't know how old it
> >> is)
> >> 
> >> http://opensource.dyc.edu/ramdisk-vs-ramfs
> >> 
> >> Switching back seems to provide a more stable environement
> >> kp
> > 
> > Andrew;
> > 
> > can/will you make the changes necessary? I guess you're the one who knows
> > best what has changed  moving to initramfs (only) and what needs to be
> > done to have initramfs with rootfs.
> > 
> > I consider the issue described above as serious and like  to get it
> > solved for beta2.
> > 
> > Anything else that anyone considers as showstopper for a new beta
> > version?
> > 
> > kp
> 
> Yes, I'll make it in near future. It'll require splitting initrc script
> to 2 parts - 1st part for preparing tmpfs and switch_root in it, and 2nd
> part - to finish init.

Great!

kp

------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 

_______________________________________________
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Reply via email to