Hello,

When booting an Alix box with big CF card installed (2GB) the boot process seems to hang for about 3-5 minutes at the following point:

switching to jffs2
mini_fo: using base directory: /
mini_fo: using storage directory: /jffs
- init -

Looks like it's doing something with jffs2 partition.

Does anyone know, is it possible to speed this process up without reducing a partition size?

Kind Regards

JFFS file system mount time is proportional to filesystem size. JFFS should read some data at mount time and unfortunately, amount of these data to process is directly proportional to filesystem size. So, you WILL have this issue with JFFS.

Do not use JFFS2 for huge partitions, ever. And take into consideration that CF cards are coming with their own built-in controller which manages wear leveling, addresses transations, physical properties handling (like erase boundaries) on it's own. So any general-purpose filesystem should be fine (with some notes - see below if interested).

JFFS has been designed for use cases where quite small "raw" flash device (usually just single IC) attached to CPU bus without any sophisticated controllers between CPU and flash, so main system CPU have to bother itself with some things which are not visible otherwise (when using flash cards with integrated controllers hiding these things, etc).

So JFFS bothers itself with wear leveling, writes alignment on erase boundaries, addresses translations, etc while this only needed when flash ICs are directly attached to CPU so there is nobody except CPU itself to bother with such low-level tasks.

So, for example, small boot flash of CPU (where usually system is stored) is a good place to use JFFS and JFFS really useful since in such case filesystem MUST take flash physical properties into account. Most huge JFFS real-world use I know is a 256Mb NAND flash of Nokia N8x0 devices. Anything more than that is, uhm, not recommended. Due to mount times

Huge cards which are supplied with FAT formatting are not a right place for JFFS at all since at very most JFFS will do the same job as internal card controller already does, there is no gain doing so but extra overhead happens.

So, summary is: to speed things up, just use some another filesystem on your card. I'm personally would prefer EXT2/3 or XFS in your scenario but it's matter of preferences, tastes, etc.

P.S. Actually, "sophisticated" cards (SD, MMC, CF, ...) are hiding their true geometry from the world and are trying to look like traditional disk-based devices. So there is no need to have special-purpose filesystem on such card. But please note: erasing "default" filesystem (usually, FAT) from card is not a great idea at all and can lead to sub-optimal results. But you already did it so you have a freedom of choice which FS to use. Because you lack true geometry knowledge of ICs anyway, as well as knowledge how it's built-in controller works. So you will have a equally hard times putting ANY filesystem into proper alignments and sizes so you do not have to stick to fat and can use some better filesystem since there is nothing to lose left already but maybe something to gain vs (still sub-optimally placed) FAT . Default vendor's FAT formatting done with a geometry knowledge and knowledge how controller works, so FAT's structures are aligned in a very tricky manner to match physical boundaries, etc. What is the penalty for misplacement? Up to 2x times loss of write speed + 2x more writes (and hence 2x faster wearing) if it has turned out that filesystem clusters (blocks or whatever) are clashing with physical location of blocks on ICs (technically, when FS block crosses NAND page boundaries, it is a "poor" scenario since to overwrite one FS block, two pages should be erased while it could be possible to satisfy write with single page rewrite if FS alignment is "proper" to flash ICs physics).

(Last edited by Drone on 22 Jun 2009, 20:17)

Drone, thank you for such indepth answer.

Drone, am I right that after I've destroyed the original partiotion table there's no way I can recover information about its original page aligment?

(Last edited by nas on 22 Jun 2009, 20:28)

Hi Drone,
Considering your valuable input about CF cards: what would be the best file system option for building an OpenWRT image for an Alix Board?
How can I boot OpenWRT from a CF without erasing its optimal FAT system?

(Last edited by patpat on 1 Dec 2009, 20:09)

I would not consider the FAT fs as an optimal fs :-D
If you ever need it again on a CF, format it using Windows or a digicam ;-)
I'm using ext3 on all my OpenWrt boxes with USB/CF storage, and on the CF of my ALIX2C3 running ubuntu server 8.04 (the HD uses xfs).
The advantage of xfs over ext3 is the availablilty of an online defrag tool, which is not needed on a flash device due to the fast access time.

If you read Drone’s inputs he states the CompactFlash cards are “optimized” on read/write speed for the file system they originally bring; FAT.
From that point my question: Is there any way we can use that FAT system that makes the CF perform as the factory says and booting OpenWRT at the same time??

Did you perform any comparisons using different fs on a CF using an openwrt device?

If a CF card only brings the quoted performance when used with the "original" formatting, 99,9% of all CF cards would run at suboptimal performance because they where formatted inside a digicam or with a windows computer.
If the main cause of a potential problem are fs blocks crossing flash page boundaries, the FAT fs seems especially vulnerable to this, because of it's large default cluster size. Using a decent fs with a smaller block size should be less prone to that problem.

Using FAT for the linux root fs is not a good idea, because it does not support any user rights for files and directories.
If you can't live with that (imaginary?) speed problem, run Windows CE on your device, or use a real hard disk with linux ;-)

MMCM
I'm just asking here... it seems you do not agree with Drone's sayings...