Messages in this thread | | | Date | Thu, 26 Aug 2004 17:44:51 +0100 | From | Jamie Lokier <> | Subject | Re: silent semantic changes with reiser4 |
| |
Christoph Hellwig wrote: > or placing this into a userspace helper that the kernel can invoke > transparently.
Yes, exactly this for most file formats. Ideally, with _some_ user control over the handlers for their own files a bit like Hurd.
Not just archive files: metadata pulled from audio files, images, distro packages, etc. In other words much the same as Gnome and KDE's things, but with more emphasis on metadata extractors and efficient on-disk cache interaction, and a sane page-cache coherency interface (possibly FUSE).
Metadata extraction is useful for search and indexing purposes. (That, and a way to hook change notifications up with indexers -- again comes with any proper coherency interface).
For new applications using a container, it's tempting to want one format which is optimised for this. But really many applications want to write XML or compressed XML, or something else that isn't especially efficient but is easy to work with on many OSes. We should support applications whatever format they need to work with, if providing an interior view as a directory is useful for them. (This implies applications can introduce their own formats for files they need to operate on.) By the way, lazy updating of containers is an even bigger advantage if you have to use XML as the flat format, because the savings from not serialising when you don't need to are more pronounced.
For some applications the "content" isn't structured in a way which maps naturally to a plain archive file. Hans' /etc/passwd is a simple example: at least one of the "flat" representations, when there are enough entries, probably ought to be a DB file for faster lookup. (Though, it would be great if /etc/passwd could automagically get fast lookup due to an automagic underlying representation, while still appearing to be a flat file when you cat it).
Also, imagine "cd" into a MySQL table file. It might just work.
By the way, we don't need containers to waste huge amounts of space like the Microsoft Word "fast save" documents did. Because our containers are created on demand, there is no performance advantage in them having unused holes, unlike the case were Word was saving changes periodically.
-- Jamie
- 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/
| |