Sooner or later, we are going to want to add some kinds of
metadata in the inode. Forget about user metadata for just
a moment, and consider ACLs.
As it turns out, you really want to treat ACL's as a special case for
two major reasons. First of all, performance is extremely important;
access checks on files is something which happens often and needs to
happen quickly, so grovelling around in a resource fork looking for the
ACL is not a good idea. Secondly, ACL's are often duplicated; it will
be very common for all of the files in a particular source tree (say,
everything under /usr/src/linux for example) to have the same ACL.
So a better way to handle ACL's is to have an ACL's defined by ACL
numbers, and to store ACL numbers in inodes. The ext2 kernel code would
maintain an in-memory ACL cache so that when it is doing access checks,
it can do so very quickly.
For things like adding support for the privilege/capability masks for
executables, yes, the plan was to add a generic capability for storing
kernel-specific metadata, since that data does not need to be accessed
nearly as often. (However, for commonly used executables we will still
want to cache capability masks.)
The point has been made (and it is correct) that kernel
metadata is fundamentally different than user metadata.
But this doesn't necessarily mean that they two cannot
be stored together.
An important reason why you don't want to store user metadata and kernel
metadata in the same place is that kernel metadata tends to be small.
For example, the capability masks will fit within 20-30 bytes at most.
In contrast, user metadata could be huge --- spanning possibly megabytes
of icones, string tables, sound files, etc. On the Macintosh, it is not
unheard of for the resource fork to be far larger than the data fork.
This means that if we engineer a solution that allows for user metadata,
we will need to make a much heavier weight solution that would probably
involve a second inode. My original design for dealing with the kernel
metadata required by the privilege/capability masks involved using a
linked list of disk blocks to store the kernel metadata. This is faster
(since it doesn't require an inode lookup) and more space efficient.
(Consider what would happen if every file had an ACL, and ACL's were
stored in the kernel/user metadata inode; then every file would consume
two inodes, and every file would have at least extra 1k block to store
the ACL, and a file permissions check would require reading an extra
inode and then seeking to another block to read in the ACL.)
If we avoid storing user metadata, we can have a lighterweight, more
efficient implementation. We also avoid needing to define a
non-standard API for storing user metadata, and we avoid tempting
application programmers to write non-portable code that won't work on
any other Unix system in the world.
- 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