Daniel Phillips wrote:
> Curtis Anderson wrote:
> > 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!
>
> This is where your lucid exposition gets murky. It's not enough to
> simply document it, you actually have to make the changes in libc, or
> wherever you plan to make them. Documentation isn't enough.
You caught me, that last bit of my story was rhetoric. :-)
There is also a real issue there. You can make an argument that code to
support directory-hack EA's should be in libc so that all the standard
utility programs get it for free. I'm worried that basic assumptions that
lots of those utilities make about "files" are now broken and that the
utility will work correctly in most cases, but not in some. It will
appear to work until some corner case is hit, the net effect being an
overall drop in predictability/correctness for the system. I think it
is better to force a real engineering look at a utility in order to add
support for attributes rather than taking your chances with slipping them
in underneath and hoping they work right. This is independent of which
style of EA's we are talking about.
For example, "mv" will devolve to "cp" when the source and destination
filesystems are different. So "mv" will preserve attributes for some
operations, and will drop them on the floor for others. Unexpected by the
average user, and therefore bad.
In another example, IRIX uses dynamic linking of shared libraries like
most other Unices. It is much more efficient if all of the shared libraries
are set up to "load" into different address ranges when a process starts
instead of going through some address conflict resolution and dynamic
relocation of the library. There is a tool in IRIX that will examine all
shared libraries when new ones are installed and will assign non-conflicting
addresses to each (I think the addr goes with the lib, but it could have
been the addr going with the program, its been a long time). That tool
does not modify a shared library in place, there is too much risk of
half-finished updates scrogging a system if a crash happens. The tool
copies the shared library, making changes along the way, and then does a
rename() to atomically get it into place. Naturally, we didn't know it
used copying instead of update-in-place, and therefore had not thought to
teach it about copying EA's until problems came up and we traced it back.
In colloquial, "there be dragons here".
> > 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".
>
> So it's not clear how you reached to the conclusion that directories
> shouldn't be pressed into service as compound files. I'm sure you have
> a reason, but it wasn't revealed here!
It's an aesthetics argument. There are no new features in a directory-based
streams-style attribute mechanism over basic filesystem semantics. It would
be bad to confuse things by trying to say that this is "new" or "different"
when it is not.
The argument is also recursive, although I didn't bring that out in my
email. Once I have such heavyweight streams-style attributes, maybe I
need to store some additional pieces of information about that stream.
For example, if I have an audio clip attribute where I say "My name is
Linus and my OS is called Linux", I still need to know the encoding format
and bit rates to reproduce the accent correctly. I've now claimed I need
attributes of attributes, possibly with ACLs, timestamps, etc, etc. This
is really just a call for hierarchically organized information, ie:
directories and subdirectories. Which is again, what we have now.
The problem with streams-style attributes comes from stepping onto the
slippery slope of trying to put too much generality into it. I chose the
block-access style of API so that there would be no temptation to start
down that slope.
Thanks,
Curtis
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
