First let me state that I realy shouldn't be writin posts like this. Altough I think that people online usualy do talk/write like this. Somebody new to the list may not appreciate it. So for everyone not enjoying the foklore, sorry.
This makes me think also about what is said about second life (and world of warcraft). People online talk much more direct, but people might not always apreciate it. Anyway if anybody would like to build a virtual presence for FreeDOS in second life. That would be so cool. Imre >----- Oorspronkelijk bericht ----- >Van: Imre Leber [mailto:[EMAIL PROTECTED] >Verzonden: donderdag, maart 20, 2008 12:43 PM >Aan: freedos-devel@lists.sourceforge.net >Onderwerp: Re: [Freedos-devel] compressed FAT filesystems > > >Does the fact that all this runs on linux slip your mind (like in no way >interesting for the stated purpose). > >Seriously, how is any of that supposed to be running in DOS? It's mainly not >even embedded (like a set of operating system services you can embed in a >microcontroller application). > >Imre > > >>----- Oorspronkelijk bericht ----- >>Van: Eric Auer [mailto:[EMAIL PROTECTED] >>Verzonden: donderdag, maart 20, 2008 03:33 AM >>Aan: freedos-devel@lists.sourceforge.net >>Onderwerp: Re: [Freedos-devel] compressed FAT filesystems >> >> >>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 >>Freedos-devel@lists.sourceforge.net >>https://lists.sourceforge.net/lists/listinfo/freedos-devel >> >> > > > >------------------------------------------------------------------------- >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 >Freedos-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/freedos-devel > > ------------------------------------------------------------------------- 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
