> 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.
...
> what change will we make to the
> inode to hold ACLs? Shall we add a single purpose item,
> and condemn ourselves to inventing a new filesystem type
> for the next change, or do we add something to the inode
> that is flexable enough to support new metadata that we
> haven't even thought of yet? Isn't this second solution
> more consistent with the philosophy of Unix, anyway?
>
> An inode based resource fork could give us this flexability
> and, if planned carefully, would allow us to store metadata
> that the kernel doesn't care about. Even if we only consider
> kernel metadata in a resource fork, some kernels may not
> have all metadata features compiled in, so there would have
> to be an easy way for the kernel to ignore metadata that
> it didn't understand. It is a small step, I think, from
> this ability to ignore some kernel metadata to having
> metadata that the kernel is never intended to interpret.
>
> 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. If we decide we need to store kernel
> metadata in the inode (and I realize this requirement
> may not have been established) we might be able to store
> some kinds of user metadata in the same facility without
> an unreasonable degree of additional complication. If
> an additional type of user metadata would unduly
> complicate the inode based metadata scheme, would could
> condemn it to implementation through these external
> metadata files, without giving up the advantages of
> inode based user metadata in those cases where it is
> easy.
It sure seems that Digital Unix does that. The UFS inode has
a "property list block number" which points to this structure:
/* The real size of this may be computed as the sum of:
*
* sizeof(property_list_entry)
* (name_length + 7) &~ 7
* (value_length_entry + 7) &~ 7
*/
struct property_list_entry {
__u64 offset_to_next;
__u64 version_magic;
__u64 entry_size;
__s32 next_fs_blk;
__s32 unused;
__u32 flags;
__u32 inode;
__u64 value_length;
__u64 value_length_entry;
__u64 name_length;
/***** The following are variable length *****/
/* char name[name_length]; */
/* char value[value_length_entry]; */
}
It seems that a large number of these variable-length structures could
be attacted to one inode. There is already a Linux project doing
something like that, with the useless i_translator field.
>From another linux-kernel thread, one use would be undelete information.
One filename would be stored when a file is created, linked to, or
renamed. While unreliable with multiple links, it would cover most of
the troubles with undelete.
-
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