lkml.org 
[lkml]   [1998]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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

    \
     
     \ /
      Last update: 2005-03-22 13:44    [W:0.029 / U:122.632 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site