> 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.
Hmmmm.... How about this. ACLs are stored in the directories. Each directory
has a default creation ACL and, separately, a default ACL. Any file with an
ACL different from the default ACL has an ACL stored for it in the directory.
So,
filename NULL
filename David 32432 or whatever
Another possibility I like goes like this: Use the idea of ACL tables, but put
them in each directory. They would then store the ACLs for the directory.
This would perhaps avoid some of the problems.
>
>
> 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
-
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