Messages in this thread | | | From | "Acy James Stapp" <> | Subject | Re: (reiserfs) Re: File systems are semantically impoverished compared to database and keyword systems: it is time to change! | Date | Wed, 23 Jun 1999 23:35:33 -0500 |
| |
Christopher B. Browne wrote:
| Theodore T'so wrote: | > So, here's a quick back-of-the-envelope design for a completely | > user-space solution for folks who have been asking for multi-fork files. | > ..... | > extra extensions to the libc, which might be considered kludgy, I | > believe it is no worse than the Microsoft NTFS-style "reparse points" | > suggestion which was offered to the kernel list in the last day or so. | | Some of what has taken place has been "pie in the sky" thinking, without | a down-to-earth enumeration of the set of constraints that will be | expected. Lots of "cool ideas," but no real requirements analysis.
"Reparse points" or filters could be even more easily (and perhaps more fruitfully) implemented as part of the standard library. The major difference would be the location of the metadata: the filter, the sequence, and perhaps a default presentation. In a user space libc implementation, these would necessarily be stored as regular files in the filesystem. The most obvious solution is [path-outside-albod]/albodname/.albod/filter --> /lib/modules/fs/albodfilter.o [path-outside-albod]/albodname/.albod/default --> ../albodname.txt [path-outside-albod]/albodname/.albod/order etc.
This introduces another directory access on every open (to see if a directory has an .albod entry and hence should be treated as a file) even for non-albod aware apps. This might be a noticeable performance hit for certain apps.
One big advantage is that this doesn't introduce a new namespace. A kernel mode implementation could be made to provide services through the .albod/ interface in order to preserve transparency between user-mode and kernel-mode implementations.
Other advantages of a user-space implementation are fewer security concerns and portability to other OSs.
However, the above directory structure wouldn't allow a file to impersonate a directory. In order to do so, the albod metadata would have to exist in some place other than a subdirectory of the albod (since the albod is a file). i.e. [path-outside-albod]/.albodfilters/albodname --> /lib/modules/fs/albodfilter.o Or even [path-outside-albod]/.albod/albodname/filter --> /lib/modules/fs/albodfilter.o Each has it's advantages and disadvantages.
Oh, and I think "albod" is a great acronym. I'm going to start using it in my daily conversations. -- Acy Stapp / astapp@austin.rr.com Now Playing: "Sheila", Morphine, [Cure For Pain]
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |