L. Adrian Griffis said:
[snip many excellent points)
> 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.
Big problem here. Currently, permissions are stored in a file's directory,
one set for each link. If an ACL is stored via inode, won't that break this?
How about putting the ACLs in the directories?
> 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.
>
> > If we avoid storing user metadata, we can have a lighterweight, more
> > efficient implementation.
>
> I addressed this very point in that paragraph you forgot to include
> from my last message. See above.
>
> > 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.
>
> This is simply incomprehensable. In case you haven't noticed,
> there has been a certain amount of interrest in user metadata.
> There is no widely accepted standard API for user metadata that
> I know of. If there isn't currently a standard API, but people
> want the feature, doesn't it seem to you that there is a need
> for an API? Doesn't this new API need to start somewhere?? Is
> there a metadata API standard that you know of that we should
> be thinking about as we venture down the road to metadata? If
> there is one, we should consider it; If not, this same argument
> would apply wherever we attempt to invent the new API. How can
> we ever have a new API without putting aside this argument?
> Would you rather wait around for Bill Gates to invent the API,
> and then try to implement it on Linux and hold your breakfast
> down at the same time.
>
> ---
> L. Adrian Griffis - KE6CSX - adrian@idir.net
>
> -
> 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