Messages in this thread | | | Date | Fri, 11 Sep 1998 23:54:17 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: 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
| |