> 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