lkml.org 
[lkml]   [1998]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Implementing Meta File information in Linux
   Date: Fri, 11 Sep 1998 21:51:15 -0500
From: "L. Adrian Griffis" <adrian@idir.net>

> 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.

This is not implausible, but imagine a server at an ISP or a University.
It might have lots of different accounts with people setting different
ACL's. Would this approach scale well? Shall we have another standard
error value like EACLTABLEFULL?

The observation still holds; if you have many different users, each user
will typically have multiple files and directories, and files within the
same directory will often have the same ACL's.

Take for example a user using MH; each e-mail message stored in an MH
folder is a separate file, and they are all likely to have the same
Access Control List. Whether or not a system is single-user or
multi-user doesn't change the fact that all of the files in the folder
will likely have the same protections. By storing all ACL's for a
particular filesystem in a central place, and then assigning each ACL
with a single number, when the user scans his/her MH folder, the kernel
can read in the ACL once, and then see that all of the files in the MH
folder refer to the same ACL, which can be cached in the ACL cache.

(By the way, Remy Card has implemented an Alpha version of this already,
and he and I discussed the design before he started implementation. So
this isn't just idle chatter).

Where in an ext2 inode would you put this ACL number? Can we really
do this in an ext2 filesystem or would be have to invent a new one?
If we have to invent a new one, shouldn't we try to get more from
all the trouble we would have to go through?

Actually, there are two entries in the ext2 inode reserved for the ACL
numbers. One is only used for directories, and specifies the default
creation ACL to be used for new files created in that directory, and the
other specifies the ACL for inode (whether it be a file or a directory).

We had left room in the ext2 filesystem to support ACL's from the very
beginning, including reserving two inodes which would be used for
storing the access control list and the access control list entries.

You won't get a community of non-administrator users to
go out of their way to tell the OS that it can use a
common ACL table entry for all the files that really
have the same list.

That's what the ACL cache is for; it's extremely likely that if the user
changes the ACL settings on a file, he/she will be setting it to match
the ACL setting on some other file. This is not guaranteed, but in
practice it will minimize duplications in the ACL table. Note that a
very common operation will be changing the access controls for all of
the files in a single directory, just as it's relatively common for
users to type "chmod 600 *".

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.

Also note that each directory has a default file creation acl; when you
create a new file, all the filesystem has to do is to copy the acl from
the directory's default creation acl field to the new file's acl field,
and then bump the ref count on the ACL.

Where did this second inode come from? The "resource fork" would be
tracked by the same inode as the data fork. If we have multiple
hard links in separate directories to a single file, the file's
inode is the obvious way to get at the metadata. If we put a
pointer to a different inode for metadata in the main data inode,
we have modified the inode, so we already have to invent a new
filesystem type. As long as we are modifying the inode and
inventing a new filesystem type, why not just put the "resource
fork" in the inode, and make that our change. For those files
that need metadata, we would still have to read a block; You're
right about that. But the other approaches have their disadvantages
too.

For all of the designs which I have outlined, they are all can be
implemented with only minor extensions to the ext2 filesystem format.
These changes can be made in a backwards-compatible fashion without
forcing people to backup, reformat, and restore their filesystems in
order to enjoy these new features. The ext2 filesystem was carefully
designed to allow this kind of incremental extension. Perhaps you
didn't realized this when you made your assertion that any kind of
change required a new filesystem type. This is in fact not true.

Because people generally like stability, I made the assumption that we
were discussion how we might add support for the "resource fork" into
the existing ext2 filesystem, and in that case, if you are going to
architect a solution where you store arbitrarily large amounts of data
in a "resource fork", there really isn't any other solution than using a
second inode to store the resource fork. Remember that both the
resource fork and the main data fork can get extended at any time during
the life of the file. So you need a separate set of direct and indirect
block pointers for the resource fork and the main data fork of the file;
there isn't enough space in the inode to store a second set of block
pointers.

You could use the linked-list approach for the resource fork --- that's
why I had planned to store the kernel metadata --- but such an approach
doesn't work if you have to store arbitrarily large amounts of data,
since a linked list is a very fragile filesystem data structure; one
corrupted block and you won't be able to find the rest of the linked
list. (Also consider what would happen if the ACL entry gets stored at
the very end of the several megabyte-long resource fork; the kernel
would have to search through several megabytes before finally finding
the ACL in a linked list implementation.)

The bottom line is that there is room for an extra pointer to store a
pointer to a block containing kernel-metadata, which in the unlikely
event where the kernel metadata exceeded one block, could be extended
via a linked-list arrangement. There is not space for an additional set
of blocks for a resource fork.

On the other hand, if you are thinking about creating your own
filesystem which has support for a new resource fork, go ahead and try!
You will find that making an efficient and robust filesystem is harder
than you think.

This is simply incomprehensable. In case you haven't noticed,
there has been a certain amount of interrest in user metadata.

There is a lot of interest in many things in this world. For example,
many people have a deadly fascination with crack cocaine. That doesn't
make the interest correct, or even healthy.

In the case of user metadata, I have not yet seen a single instance
where the use of user metadata conferred any kind of real advantage
which could not be achieved in some other way. So I see no real
benefits, and many disadvantages. As a result, it's not something for
which I will invest my own personal time to do; I think it's a waste of
time.

If you want to development your own filesystem with this non-stnadard
extension, and your own non-standard, non-portable API, there is of
course nothing stopping you from doing that. I wouldn't recommend that
application writers and desktop designers who are interested in portable
program use this interface, but obviously it is up to them to decide
whether they want to use it.

- 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:3.890 / U:0.584 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site