[BusyBox] Disk space saving file systems

[David Chow]

>
>
>>2. Most of the appliance Linux devices have a backup copy of the OS in 
>>ROM. For the first time it boots, it extract files into RAM. Where the 
>>fs in RAM contains symbolic links back to the rom for read-only binaries 
>>or program files. This way, you don't have to store binaries in RAM but 
>>only files that need read-write to. However, each symbolic link consumes 
>>a disk block and inode data. For a lots of symlinks, it consumes quite a 
>>lot of RAM spaces. Also, it is not transparent, developers need to 
>>manually create those links and test with after making changes to the 
>>ROM . This created overheads to developers which result in time 
>>consuming testing. If a file system (or directory) can be copied to the 
>>romfs and directly accessed as a read/write fs, it will behave like a 
>>normal Linux OS, thus developers can make changes directly in the 
>>embedded Linux OS instead of updating the ROM everytime during the 
>>development. Developers only need to copy the final result out and flash 
>>into the ROM using the latest copy to produce the final OS result. The 
>>file system is called Union File System (unionfs) but is not quite the 
>>one in BSD.
>>
>>    
>>
>
>While I'm sure all this provides advanced features that many developers
>desire, don't forget about cramfs. Not only does your image use minimal
>rom space, but only pages currently in use are in RAM. As a hack, any
>directories that need rw can be mounted at boot (such at /tmp), of
>course, files you put into /tmp won't get compressed in ram.
>  
>
Yes, of course we know about camfs The reason we want to combine unionfs 
and cogofs is to make compressible (possible with encryption too), 
read-writeable, unioned fs of a ROM source and RAM source to provide 
maximum saving by eliminating RAM based symbolic links and inodes or 
eliminate the porting work of apps. Since we have developers tried to 
fit a Chinese embedded Linux into a pocket PC which the fonts itself 
cost 12MB . It is quite impossible to do something without compression. 
In many cases, PDAs need the ability of installing third party software, 
which they will not be able to put into cramfs. I would like to collect 
comments from everywhere so that we can know about the needs of embedded 
Linux developers.  Thanks.

regards,
David