JFFS2 root file system from CF

[miniwilliam@gmail.com]

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

[Geronimo W. Christ Esq]

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.

[Sebastian]

"Geronimo W. Christ Esq" <thegreatsuprendo@hotmail.com> 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

[Sebastian]

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

Sebastian

[Graham Baxter]

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" <thegreatsuprendo@hotmail.com> 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.

[Geronimo W. Christ Esq]

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.

[Michael Schnell]

> 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

[miniwilliam@gmail.com]

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.

[Robert Kaiser]

In article <1141682202.16414.0@iris.uk.clara.net>,
"Geronimo W. Christ Esq" <thegreatsuprendo@hotmail.com> 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

[Robert Kaiser]

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

[M.Kmann]

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

[Tessy]

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"

[Michael Schnell]

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

[Tessy]

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

[Geronimo W. Christ Esq]

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.

[Robert Kaiser]

In article <1141952347.6634.0@damia.uk.clara.net>,
"Geronimo W. Christ Esq" <thegreatsuprendo@hotmail.com> 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

[Michael Schnell]

> 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

[Robert Kaiser]

In article <dusra6$uh8$03$1@news.t-online.com>,
Michael Schnell <mschnell_at_bschnell_dot_de@aol.com> 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

[Jim Jackson]

Robert Kaiser <bitbucket@invalid-domain-see-sig.nil306-1.cs.fh-wiesbaden.de> 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.