JFFS2 root file system from 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

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

Sebastian

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:// snipped-for-privacy@NOSPAMgbsw.co.uk

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.

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.

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

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.

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.

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

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

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

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"

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

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.

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.

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.

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

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

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

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

Cheers

Rob

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.