http://yarchive.net/comp/linux/reiser4.html
Jamie Lokier renames the thread and argues (2004-09-01): The argument for fs assistance in handling archives:
“Now, why would we bother with all this? I see three reasons: convenience, time efficiency, and storage efficiency.”
- convenience: nice to just “cd” into a file
- time efficiency: many document file formats are archives - whan manipulating individual parts, it might be more efficient if the FS/OS caches the decompressed state so that individual accesses do not require complete recompression.
- space efficiency: the OS can optimize storage if it can decide whether to store files unpacked or packed (?)
“absolute coherency just isn't an option, because it's just not possible to try to atomically update a view at the same time somebody else is writing to the “main file”.”
Hans Reiser seems to suggest that multiple subfiles might be seen as a single coherent "commit" (?)
- “oh, then everything is a file”: https://marc.info/?l=linux-kernel&m=109447811417137&w=2
2007-04-23, Theodore Tso: “One of the big problems of using a filesystem as a DB is the system call overheads. If you use huge numbers of tiny files, then each attempt read an atom of information from the DB takes three system calls — an open(), read(), and close(), with all of the overheads in terms of dentry and inode cache.”
- 2007-05-22: Miklos Szeredi suggests it again (without Reiser4): https://marc.info/?l=linux-fsdevel&m=117986025907108
- use for archive files
- “Others might suggest accessing streams, resource forks or extended attributes through such an interface”
- Patch, based on avfs
Examples from related work for using FAD for: