Hi Imre, > Which free/open compressed embedded filesystems would that be?
Browsing wikipedia a bit gives me quite a few READONLY free and open source compressed filesystems, several of which are useful for embedded systems. For writeability, you would typically have to alloc new space in your filesystem whenever a changed cluster no longer fits (in compressed form) into where it was before. Then you need the ability to have the storage locations of the cluster contents be nonlinear, and you need some way to find unused areas and either re-use them on the fly or defrag them out of the filesystem with an "offline" (while the filesystem is not used) tool. Luckily a readonly compressed filesystem is very useful for various things already, so you can make people happy with one of the simple readonly systems listed below :-). http://en.wikipedia.org/wiki/Cramfs - for ROM, GPLed, uses zlib, each "page" is compressed separately, metadata is not compressed, max 16 MB / file, 256 MB / filesystem http://en.wikipedia.org/wiki/SquashFS - GPLed, readonly, uses gzip, used for several LiveCD versions of Linuxes, compresses data and metadata in chunks of up to 1 MB each... Max 2^64 bytes per file. Default block size 128 kB. http://en.wikipedia.org/wiki/Zisofs - Linux, basically ISO9660 with extra flag to mark compressed files, it seems ;-). This means that uncompressed files on Zisofs can be accessed by any ISO9660 capable driver and operating system :-). http://en.wikipedia.org/wiki/Cloop - Linux, simply a wrapper to store a compressed block device image on a block device, it seems. Compressed images contain a "seek index with compressed and un- compressed block sizes in pairs" and the zlib compressed blocks. I assume you get the offset of a compressed block by summing up the sizes of the compressed blocks before it. Wikipedia says that Apple DMG has a similar design. http://logfs.org/logfs/LogFS - GPLed successor for JFFS2, for flash devices... Seems to be "work in progress" http://lxr.linux.no/linux/Documentation/filesystems/romfs.txt A really simple filesystem: Main content is a linked list of files, each file consisting of a header and the data of the file, all aligned to 16 byte boundaries. Header contains: Link, flags, size, checksum, max 15 bytes of name. You can easily introduce a flag for compressed files. The link has 28 bit (high 28 bit of offset), leaving 36 bits for flags. Flags are type (hardlink, dir, file, symlink, block device, char device, socket, fifo) plus extra info. Hardlink info: Offset pointer. Dir info: First file pointer. Device info: The major and minor number. Symlink info: None - instead, the "file content" is the symlink string. The "." and ".." of directories are stored as normal directory entries, the same idea as in FAT. > Add a compression attribute to the inode structure in LEAN. And then > put the compressed data into the file. Tools have done the same for FAT: Use an unused bit or combination of bits in the file attribute to mark a file as compressed, or use some sort of header in the file contents... The suggestion of my previous mail is a bit similar to CramFS and Cloop in design, but my main idea is to have a filesystem which stays similar to FAT and where it is easy to transform a FAT system into a compressed one with a tool and for the other way round make a compressed FAT system look like it was a normal one with a driver for the other way round, making it possible for the FreeDOS kernel to "mount" it easily :-). This includes keeping metadata very FATish, adding compression related metadata at a low profile place (eg replace the 2nd copy of the FAT) and compress only the data clusters. Eric :-) ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
