Messages in this thread | | | Date | Sat, 12 Sep 1998 18:26:43 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: Implementing Meta File information in Linux |
| |
Date: Sat, 12 Sep 1998 10:58:17 -0500 From: "L. Adrian Griffis" <adrian@idir.net>
> Yes this is not perfect. However, even if there are a few identical > ACL's stored in the central ACL table, this will still be vastly more > efficient than storing a separate ACL for every single file in the ext2 > filesystem.
So you are willing to live with just the benifits of cache hits. Interresting... I agree that this will avoid the most costly parts of a search for commonality, but still yield some benefits for the cases where we get a cache hit.
Actually, I expect that most of the time, searching the ACL cache to see if there is a pre-existing ACL when you are assigning an ACL to an inode is going to be almost as effective as doing a full commonality search. This is an engineering judgement, sure, but the idea is to get most of the benefits of storage efficiency and caching effectiveness, without having to pay the costs of having to search the entire ACL store each time we do an ACL set operation.
You were arguing that we should avoid creating a non-standard API, and I submit that you yourself do not believe this; You are, afterall, creating a new facility, these ext2 ACLs, right? Aren't you going to create a new API for it? Why, in principle, does your argument make sense for "storing user metadata" but not for your ACLs?
Creating an API is all fine and good, and in the past, I've argued for this --- along with an implementation which stored the file metadata in a separate per-filesystem (and possibly per-user) central database.
Creating a kernel API which works by storing the file metadata inside a non-standard, Linux-only filesystem *would* be encouraging application programmers to write non-portable programs, and that's what I object to.
You were arguing that we should avoid creating a non-standard API, and I submit that you yourself do not believe this; You are, afterall, creating a new facility, these ext2 ACLs, right? Aren't you going to create a new API for it? Why, in principle, does your argument make sense for "storing user metadata" but not for your ACLs?
Actually, there already is a proposed POSIX standard interface which for setting and reading out access control lists. It is implemented on a number of other commercial operating systems, such as Trusted HP-UX and Trusted Solaris. (Yes, you have to pay extra if you want ACL support --- although these systems also have a number of other extra features beyond just ACL support.)
My concern is not so much with the non-standard API, though, but encouraging application writers to write non-portable programs that only work under Linux.
And of course, if you've ever had to deal with moving Macintosh multi-fork files across the Internet (where if you forget to binhex the file first, you'll end up trashing it because you'll lose the resource fork), you'll understand my additional concerns about encouraging application writers to use this functionality at all, whether or not whether it's done in the filesystem or via a user-mode shared library API.
It makes sense for information which the desktop stores for its purposes (such as icon management); but it should be the case that you don't lose anything vital if the resource fork gets dropped after it got copied via some application or protocol that doesn't understand the non-standard resource fork. In practice, this means that most of the time application writers *shouldn't* be trying to use resource forks. Desktop systems, sure; but application data should be stored in the main data fork, since anything in the resource fork may disappear unexpectedly.
- Ted
- 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/faq.html
| |