This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

dm365在jffs2文件系统下,反复重启后,启动时间越来越慢!

dear  大神们:

环境:DM365开发板 dvsdk_dm365_4_02_00_06,linux-2.6.32.17-psp03.01.01.39

在我反复上电重启dm365后,发现上电启动的时间越来越慢,主要延长的时间在Starting udev后,最开始只要在Starting udev后只要30秒;在重启了上百次后,竟然在Starting udev后需要60秒才完成。

不知道怎么回事?是否文件系统需要某些优化的地方呢??谢谢

[   14.600000] __do_fb_ioctl__
[   14.620000]
[   14.620000] __do_fb_ioctl__argp is 0xbe800b84, var is 0x14,ret is 20
[   14.620000]
[   14.620000] __do_fb_ioctl__
[   14.640000]
[   14.640000] __do_fb_ioctl__argp is 0xbe800b84, var is 0x14,ret is 20
Starting udev
[   25.410000] udev: starting version 141
Remounting root file system...
Caching udev devnodes
Populating dev cachemv: cannot rename '/tmp/devices': No such file or directory
[   39.530000] NET: Registered protocol family 10
ALSA: Restoring mixer settings...
Configuring network interfaces... done.
Setting up IP spoofing protection: rp_filter.
/usr/sbin/alsactl: load_state:1610: No soundcards found...
hwclock: can't open '/dev/misc/rtc': No such file or directory
INIT: Entering runlevel: 5
Starting system message bus: dbus.
Starting telnet daemon.
Starting syslogd/klogd: done
Starting thttpd.

  • 这个问题是能够用重新烧写jffs2来解决吗?

  • 这是JFFS2的特性啊

    随着使用,JFFS2上的数据会越来越乱,在启动的时候就要花很长的时间来扫描,

    启动分区可以考虑使用其它文件系统,如UBI,或是YAFFS2,或是只读的文件系统

  • 3. JFFS2 的不足之处
    3.1 挂载时间过长
    JFFS2 的挂载过程需要对闪存从头到尾的扫描,这个过程是很慢的,我们在测试中发现,挂载一个 16M 的闪存有时需要半分钟以上的时间。
    3.2 磨损平衡的随意性(random nature)
    JFFS2 对磨损平衡是用概率的方法来解决的,这很难保证磨损平衡的确定性。在某些情况下,可能造成对擦写块不必要的擦写操作;在某些情况下,又会引起对磨损平衡调整的不及时。
    3.3 很差的扩展性
    JFFS2 中有两个地方的处理是 O(N) 的,这使得它的扩展性很差。
    首先,挂载时间同闪存的大小,闪存上节点数目成正比。
    其次,虽然 JFFS2 尽可能的减少内存的占用,但通过上面对 JFFS2 的介绍我们可以知道实际上它对内存的占用量是同 i 节点数和闪存上的节点数成正比的。
    因此在实际应用中,JFFS2 最大能用在 128M 的闪存上。

    可以 多分区+ramdisk

  • Eason Wang 说:

    这个问题是能够用重新烧写jffs2来解决吗?

    可以通过重新烧写jffs2来解决,也许只要考虑更换文件系统了,谢谢