Messages in this thread | | | From | Ulrich Pfeifer <> | Subject | Cramfs fixes + mtime | Date | 10 Jun 2002 09:42:22 +0200 |
| |
Hello,
,----- | Given that cramfs will probably be used for CDs etc. as well as just | silicon ROMs, `-----
inspired by this comment in fs/cramfs/README, I tried to use cramfs for backups on a very old PC. Unpacking a 50+M uncleaned kernel tree just to compare one file was very slow compared to loopback mounting a cramfs image from CDROM.
When using mkcramfs for larger directory trees, I realized two shortcomings of mkcramfs which are already highlighted in the source:
1) mkcramfs does map all files before generating the image. That limits the number of files you can backup to 1024 on most systems.
2) mkcramfs uses an anonymous map for the resulting image. That limits the image size to the available physical memory - not enough on my box.
I resolved both issues as suggested by the comments. When solving problem 1), I removed the capability of mkcramfs to detect duplicate files. It can be re-added by e.g. storing md5sums for each file. This feature is of little use for backups, so I did not implement it.
With these two changes, I was able to generate images of up to the maximum of 256M. Then I realized that backups without storing the mtime of the files is of limited use.
The fs/cramfs/README encouraged me to extend the cramfs inode.
,----- | it might make sense to expand the inode a little from its current 12 | bytes. Inodes other than the root inode are followed by filename, so | the expansion doesn't even have to be a multiple of 4 bytes. `-----
I managed to change the kernel module to support the old and new inode format at the same time. For mkcramfs you have to choose a compile time what image format should be generated.
I also added support (compile time option) for uncompressed files as used for the Agenda romdisks. I did not add the full XIP support to the module but Agenda romdisks can be read completely.
Since I wanted to use the cramfs as backup, I felt a stand alone program to extract the image would be in order. That would probably work even with kernel series 4.5 ;-)
I slightly massaged Andrew Stitcher's uncramfs and included it.
The patch is against a 2.4.17 kernel tree. It's a little bigger than necessary because I piped mkcramfs through Lindent.
http://www.wait.de:data/agenda/cramfs+mtime-2.4.17.patch.gz (14k)
If there is enough interest, I can rework the patch for a newer kernel or make other adjustments.
Please keep me on CC; I am not subscribe to the mailing list.
Ulrich Pfeifer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |