JFFS2 root file system from CF - Embedded

This is a discussion on JFFS2 root file system from CF - Embedded ; Hi all, I have an embedded board based on PXA255 processor. The kernel and root file system are in a CF. Now the root file system is in ramdisk. However my requirement is to use JFFS2 as the root file ...

+ Reply to Thread
Results 1 to 19 of 19

Thread: JFFS2 root file system from CF

  1. JFFS2 root file system from CF

    Hi all,

    I have an embedded board based on PXA255 processor. The kernel and root
    file system are in a CF. Now the root file system is in ramdisk.

    However my requirement is to use JFFS2 as the root file system in CF. I
    have succeeded in making a JFFS2 image and mounting it once the ram
    disk is up.

    But I would like to know how can I mount the JFFS2 image from CF as
    root file system.

    Any help or useful hints will be highly appreciated.

    Thanks,
    Mini


  2. Re: JFFS2 root file system from CF

    miniwilliam@gmail.com wrote:

    > However my requirement is to use JFFS2 as the root file system in CF.


    Why ? It's a very bad idea. Use EXT3 instead.

  3. Re: JFFS2 root file system from CF

    "Geronimo W. Christ Esq" schrieb im
    Newsbeitrag news:1141677112.13293.0@iris.uk.clara.net...
    > miniwilliam@gmail.com wrote:
    >
    > > However my requirement is to use JFFS2 as the root file system in CF.

    >
    > Why ? It's a very bad idea. Use EXT3 instead.


    Or better, use EXT2 or some other non-journaling filesystem.
    Journaling does many read and write cycles and the latter may damage your CF
    in long sight.
    If you don't need to write to the root partition a true readonly-fs may be
    suitable (like romfs).

    If you want to use JFFS2 you have to compile it into the kernel, not as
    module.
    Then the kernel should ne able to mount it by itself.

    Hope this helps

    Sebastian



  4. Re: JFFS2 root file system from CF

    Sorry for the direct mail. I've got the wrong button and didn't notice.
    Sorry.

    Sebastian



  5. Re: JFFS2 root file system from CF

    It worked fine for me!

    Be careful to still mount the volatile directories to tmpfs like:

    mount -t tmpfs none /var/log
    mount -t tmpfs none /var/run
    mount -t tmpfs none /var/lock
    mount -t tmpfs none /tmp

    etc.

    --


    Regards,


    Graham Baxter
    Freelance Software Engineer (VxWorks, Linux and pSOS BSPs)
    Graham Baxter (Software) Limited
    http://www.gbsw.co.uk
    fromnewsgrp@NOSPAMgbsw.co.uk


    "Geronimo W. Christ Esq" wrote in message
    news:1141677112.13293.0@iris.uk.clara.net...
    > miniwilliam@gmail.com wrote:
    >
    >> However my requirement is to use JFFS2 as the root file system in CF.

    >
    > Why ? It's a very bad idea. Use EXT3 instead.




  6. Re: JFFS2 root file system from CF

    Sebastian wrote:

    >>>However my requirement is to use JFFS2 as the root file system in CF.

    >>
    >>Why ? It's a very bad idea. Use EXT3 instead.

    >
    > Or better, use EXT2 or some other non-journaling filesystem.


    I wouldn't recommend a non-journalling filesystem on an embedded device.
    People tend to switch embedded devices on and off since they regard them
    as appliances, rather than small computers. It helps not to have to wait
    long periods for the FS to be scanned following a reboot.

    CF devices do wear levelling and can tolerate very high levels of
    rewrite activity.

  7. Re: JFFS2 root file system from CF

    > However my requirement is to use JFFS2 as the root file system in CF.

    That does not make sense. to do its work (wear leveling), JFFS2 needs to
    know about the block structure of the underlying flash. This is not
    known for CF. So you can use any non flash aware file system just as well.

    > I have succeeded in making a JFFS2 image and mounting it once the ram
    > disk is up.
    >
    > But I would like to know how can I mount the JFFS2 image from CF as
    > root file system.
    >


    What is bad about using the RAM file system as root and some journaling
    file system on the CF that is used to read mass data and (occasionally
    !) write back some information ?

    -Michael

  8. Re: JFFS2 root file system from CF

    Thanks for the replies.

    I intend to have the minimal drivers on the ramdisk and later mount the
    root file system from CF.

    How can I unmount the ramdisk and mount the rootfs from CF? My board
    does not seem to have the pivot_root call.


  9. Re: JFFS2 root file system from CF

    In article <1141705866.069462.283130@v46g2000cwv.googlegroups. com>,
    miniwilliam@gmail.com writes:
    >
    > How can I unmount the ramdisk and mount the rootfs from CF? My board
    > does not seem to have the pivot_root call.
    >

    The pivot_root is certianly not a board feature

    Do you mean that your kernel is missing the pivot_root call, or are
    you missing the pivot_root program? I suspect the latter. If so,
    add the program to your ramdisk image.

    HTH

    Rob

    --
    Robert Kaiser email: rkaiser AT sysgo DOT com
    SYSGO AG http://www.elinos.com
    Klein-Winternheim / Germany http://www.sysgo.com


  10. Re: JFFS2 root file system from CF

    In article <1141682202.16414.0@iris.uk.clara.net>,
    "Geronimo W. Christ Esq" writes:
    > Sebastian wrote:
    >
    >>>>However my requirement is to use JFFS2 as the root file system in CF.
    >>>
    >>>Why ? It's a very bad idea. Use EXT3 instead.

    >>
    >> Or better, use EXT2 or some other non-journaling filesystem.

    >
    > I wouldn't recommend a non-journalling filesystem on an embedded device.
    > People tend to switch embedded devices on and off since they regard them
    > as appliances, rather than small computers. It helps not to have to wait
    > long periods for the FS to be scanned following a reboot.


    The only safe way to operate a CF when a sudden power loss can
    happen is to use it read-only. No matter what filesystem you use,
    if power goes off while a write access to the CF is in progress,
    it can suffer severe damage.

    >
    > CF devices do wear levelling and can tolerate very high levels of
    > rewrite activity.


    That may be true but still the number of writes is limited, so it might
    make sense to avoid unneccesary writes, especially if the number of
    writes before wear-out is not known.

    To be honest, I have never seen any reports of actually worn-out CF
    devices. It would really be nice if people who have experienced this
    could share their story.


    Rob

    --
    Robert Kaiser email: rkaiser AT sysgo DOT com
    SYSGO AG http://www.elinos.com
    Klein-Winternheim / Germany http://www.sysgo.com


  11. Re: JFFS2 root file system from CF

    Sebastian wrote:
    > Sorry for the direct mail. I've got the wrong button and didn't notice.
    > ...


    yesterday it was the wrong key, today a button, ...
    *g

  12. Re: JFFS2 root file system from CF

    Thanks! We have implemented pivot_root using system call.
    Now we are able to remount root file system.
    But there are problems.

    The kernel is compiled with devfs support. We are not able to unmount
    /dev. Is there any workarounds for this?

    Then we run /sbin/init from linuxrc script. But /sbin/init not running
    properly. It
    gives errors like "kernel panic: attempted to kill init." and
    "cant access tty: job control turned off"


  13. Re: JFFS2 root file system from CF

    BTW.: When using a CF in not write protected mode, you should make sure
    that the file system does not do unnecessary writes (e.g. for updating
    the last access date).

    Moreover, as Robert stated: The CF can be damaged by itself, if power
    goes on while a write (maybe the last write the CPU issued) is accepted
    and acknowlaged, but not internally ready. Unfortunately supposedly no
    CF comes with a maximum specification how long a write might take
    internally. The CF has some RAM buggers and might do some internal
    housekeeping after a write. To be save you need a battery backup for at
    least some 10 seconds.

    -Michael

  14. Re: JFFS2 root file system from CF


    Michael Schnell wrote:
    > BTW.: When using a CF in not write protected mode, you should make sure
    > that the file system does not do unnecessary writes (e.g. for updating
    > the last access date).
    >
    > Moreover, as Robert stated: The CF can be damaged by itself, if power
    > goes on while a write (maybe the last write the CPU issued) is accepted
    > and acknowlaged, but not internally ready. Unfortunately supposedly no
    > CF comes with a maximum specification how long a write might take
    > internally. The CF has some RAM buggers and might do some internal
    > housekeeping after a write. To be save you need a battery backup for at
    > least some 10 seconds.
    >
    > -Michael



  15. Re: JFFS2 root file system from CF

    Robert Kaiser wrote:

    >>I wouldn't recommend a non-journalling filesystem on an embedded device.
    >>People tend to switch embedded devices on and off since they regard them
    >>as appliances, rather than small computers. It helps not to have to wait
    >>long periods for the FS to be scanned following a reboot.

    >
    > The only safe way to operate a CF when a sudden power loss can
    > happen is to use it read-only. No matter what filesystem you use,
    > if power goes off while a write access to the CF is in progress,
    > it can suffer severe damage.


    I'm aware of that, but on balance using EXT3 is going to reduce the
    likelihood of long fscks and corruption compared with EXT2. Obviously if
    you power off the CF device too quickly without waiting for it to sort
    itself out internally you'll kill it.

    >>CF devices do wear levelling and can tolerate very high levels of
    >>rewrite activity.

    >
    > That may be true but still the number of writes is limited, so it might
    > make sense to avoid unneccesary writes, especially if the number of
    > writes before wear-out is not known.
    >
    > To be honest, I have never seen any reports of actually worn-out CF
    > devices. It would really be nice if people who have experienced this
    > could share their story.


    I agree that it makes sense not to treat it as a hard disk, but in
    practice I think the NAND devices they're using these days can take you
    beyond a million writes per sector. So if you erased and rewrote one
    whole sector every minute, it would take you two years doing this
    continuously to wreck it. If you have a thousand sectors and are doing
    wear levelling, then obviously you'll have 2000 years. I imagine CF
    devices these days have many more than 1000 sectors.


  16. Re: JFFS2 root file system from CF

    In article <1141952347.6634.0@damia.uk.clara.net>,
    "Geronimo W. Christ Esq" writes:
    > Robert Kaiser wrote:
    >> The only safe way to operate a CF when a sudden power loss can
    >> happen is to use it read-only. No matter what filesystem you use,
    >> if power goes off while a write access to the CF is in progress,
    >> it can suffer severe damage.

    >
    > I'm aware of that, but on balance using EXT3 is going to reduce the
    > likelihood of long fscks and corruption compared with EXT2. Obviously if
    > you power off the CF device too quickly without waiting for it to sort
    > itself out internally you'll kill it.


    OK, it might reduce the likelihood of a CF damage, but it is not
    reliable by design. I would never dare to deploy an embedded device
    like this.

    >> To be honest, I have never seen any reports of actually worn-out CF
    >> devices. It would really be nice if people who have experienced this
    >> could share their story.

    >
    > I agree that it makes sense not to treat it as a hard disk, but in
    > practice I think the NAND devices they're using these days can take you
    > beyond a million writes per sector. So if you erased and rewrote one
    > whole sector every minute, it would take you two years doing this
    > continuously to wreck it. If you have a thousand sectors and are doing
    > wear levelling, then obviously you'll have 2000 years. I imagine CF
    > devices these days have many more than 1000 sectors.


    IMO, every write access to a CF, even a single-byte one, would have
    to involve at least one complete sector rewrite internally. Thus, we'd
    have to talk about the number of write accesses (at the IDE interface).
    Given your 10^6 write cycles per sector, and 1000 sectors, we get
    10^9 write accesses until wear-out.

    But how many write accesses does a "typical" system (whatever
    that may be..) do? One per minute seems a little unrealistic to me.
    Assuming its one per second, I get something like 32 years lifespan,
    much less than your 2000 years (but still a lot for most applications).
    I have no idea if this is more or less realistic than your estimate,
    but there are just too many unknown factors involved.

    See, the problem IMHO is that everybody can only speculate about CF
    lifespans because apparently there are no proper specs. We don't know
    how the CF is organized interally (what sector size, which wear
    levelling algorithm, etc.) All we know is that CF's are primarily made
    for use in digital cameras, and I think you'll agree that the average
    write frequency of a camera is significantly lower than that of a Linux
    system.

    Thats why I asked for people to share their practical experiences
    (good or bad) wrt CF wear-out effects.

    Cheers

    Rob

    --
    Robert Kaiser email: rkaiser AT sysgo DOT com
    SYSGO AG http://www.elinos.com
    Klein-Winternheim / Germany http://www.sysgo.com


  17. Re: JFFS2 root file system from CF

    > IMO, every write access to a CF, even a single-byte one, would have
    > to involve at least one complete sector rewrite internally.


    I don't think so. You can't write a byte it always updates a sector (512
    Byte). OTOH, I suppose thy internally use some wear leveling: an erased
    block of several MB will be used to hold a bunch of sectors that is
    transferred afterwards. I don't think they will try to update a sector
    "in place" as this would need to read out and restore all other sectors
    in this block. That would take much too long.

    But as this is behavior not defined anywhere and might be different for
    different brands, your argument hold nonetheless.


    -Michael

  18. Re: JFFS2 root file system from CF

    In article ,
    Michael Schnell writes:
    >> IMO, every write access to a CF, even a single-byte one, would have
    >> to involve at least one complete sector rewrite internally.

    >
    > I don't think so. You can't write a byte it always updates a sector (512
    > Byte). OTOH, I suppose thy internally use some wear leveling: an erased
    > block of several MB will be used to hold a bunch of sectors that is
    > transferred afterwards. I don't think they will try to update a sector
    > "in place" as this would need to read out and restore all other sectors
    > in this block. That would take much too long.


    Thats exactly what I mean (I should have emphasized that with "sector"
    I meant "flash sector", aka block)

    Cheers

    Rob

    --
    Robert Kaiser email: rkaiser AT sysgo DOT com
    SYSGO AG http://www.elinos.com
    Klein-Winternheim / Germany http://www.sysgo.com

  19. Re: JFFS2 root file system from CF

    Robert Kaiser wrote:

    > But how many write accesses does a "typical" system (whatever
    > that may be..) do? One per minute seems a little unrealistic to me.
    > Assuming its one per second, I get something like 32 years lifespan,
    > much less than your 2000 years (but still a lot for most applications).
    > I have no idea if this is more or less realistic than your estimate,
    > but there are just too many unknown factors involved.


    It depends on how you have configured your system. The above may be
    typical for an untuned linux graphic desktop machine.

    Always mount with "noatime" so there is no update of the access time on a
    read, tune your applications to reduce writes. My home server, which runs
    a multitude of network services, spends most of its time with the disk
    spun down - so it is possible to reduce writes, or at least tame them.



+ Reply to Thread