[BusyBox] Disk space saving file systems

[Russ Dill]

On Thu, 2003-03-13 at 19:52, David Chow wrote:
> Hi all,
> 
> I think the reason we are on the list is looking for disk space saving 
> solution. My company provide Linux based compression file systems which 
> support various platforms. This include embedded Linux with StrongARM, 
> Xscale,x86 ... and possible to do other porting. We  also have another 
> file system that makes read-only romfs behaves read/write without 
> actually writing to the ROM. This is done by a technique of 
> copy-on-write to another fs (may be RAM of other media). The reason this 
> is also a disk space saving because of the following.
> 
> 1. For compression file systems, there are no compresion file system on 
> Linux that provides read/write access to any media (except for jffs 
> which only work on flash and mtds). We have supply the technology to 
> Chinese Linux developers which need to store truetype fonts in their 
> PDAs. Actually we help them to save at least 1/3 of RAM usage. The 
> performance is quite good because the compression engine works totally 
> in kernel space which is quicker than most of the gzip or zlib 3 times 
> more. The file system calls Cogofs which is open for free download in a 
> 45days trial. http://www.shaolinmicro.com
> 
> 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.