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 (?)

Linus Torvalds answers:

“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" (?)

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: