Hans Reiser wrote:
> You are making extended attributes different from files in more than name.
> This is deeply and fundamentally wrong.
When I developed the EA's that are in SGI's XFS, I had to decide between
block-structured attributes and stream-structured attributes. I decided
to implement block-structured EA's. The thought processes that I went
through might be interesting to some. Sorry if this is too long...
I started from a streams approach and tried to anticipate reasonable usage
and feature requests from users and application developers. You will notice
that what you see below is a stereotypical feature slippery slope.
I would like to know how much data is stored in a stream-style attribute,
so we should have a size in bytes for each attribute.
A file owner may want to limit the people who can change the value of an
attribute of a file. I think that most will agree that POSIX-style
permissions bits and groups are not something that we want push farther, so
we should use something modern like ACLs per attribute.
An application writer may want to know when an attribute was last modified.
If you are going to start keeping timestamps per attribute, then last access
time should be kept as well.
When I use open/close/read/write/lseek on a stream-style attribute, I would
like the kernel to do read-ahead and write caching for me so that I get good
performance. If two apps have the same attribute open, I'd like to have
coherency between their views of the stream. If I store an audio clip in
an attribute, I'd like to have guaranteed rate I/O support so that I can get
glitch-free playback.
Obviously, I've just described regular old files, not something new called
"extended attributes".
I need the ability to attach many attributes to a single file. Each attribute
should have a fairly long textual name. The names of attributes on one file
should not conflict with the names of attributes on another file.
I need a tool to show me the names of all the attributes of a file. It would
be grand if that tool were one of the already existing POSIX tools. The tool
that does this best is "ls". "ls" only operates on directories, however, not
on attributes of files. If I make a file look something like a directory
sometimes, that I can get "ls" to work for me.
Given a pathname for a file, I need a consistent way to open an attribute of
that file. I can append another slash after the filename and then the name
of the attribute. My directory hack above looks good again. Of course, if
I open the pathname of the file itself, I must still get the original file.
If I define a default attribute called "DATA", then I can use the value of
that attribute as the file data stream.
I want tools like "cat" to open the data stream and output that, to do
otherwise would confuse too many applications. On the other hand, I want
tools like "tar" and "cp" to pick up all of the attributes and copy/save
them. I don't want to loose all my attribute info just by moving the
file from a filesystem on one disk to one on another disk.
I could copy all of the kernel code and machinery that supports directories
into my attribute support code files, or I could go the other direction.
Since duplicate code is generally a bad idea, starting with directories is
better. What I now need is a flag in a regular old directory that says that
this is not really a directory, it is a "compound file". Once I've decided
to start from directories, I can simplify things by using the regular old
directories the kernel code provides and implement my "compound files" in
libc by simple pathname manipulation. I could even slime by a bit and put
the flag saying this is a "compound file" into the file/directory name,
something like "foo.d" instead of simply "foo".
So, I can implement stream-style "extended attributes" using code in libc
and a few conventions. I could even simply document the technique and leave
it up to the application developers who want EA's to put the required code
directly into their application. Wow, I've just implemented stream-style
extended attributes without actually writing any code at all!
In sum, "stream style extended attributes" is an oxymoron, they are neither
"extended" nor "attributes". Streams are what we have now in regular files,
and directories are perfectly suited to storing the "attributes" of that
directory, er, I should have said "file".
Since we still have a practical need for attaching small somethings to the
outside of regular files, we are left with block-structured attributes as
the API of choice.
As I said at the top, this is how I thought it through 7 years ago, reality
may have changed or your mileage may vary.
Personally, I'd vote for Stephen's "families" API. It looks like overkill
at first, and I'm not fond of arg1 saying what size/shape arg2 is in a
function call, but it will do the job of allowing common, clear access to
the wide range of underlying attribute mechanisms from a single API.
Thanks,
Curtis
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
