Hi,
On Wed, Oct 25, 2000 at 06:21:05PM -0700, Hans Reiser wrote:
> > It's not the atomicity which we need to differentiate here --- it's
> > the namespace. In other words, attribute "FOO" can coexist with named
> > stream "FOO" on the same inode, the two still being quite distinct
> > entities.
>
> filename/stream/foo and filename/attribute/FOO
>
> ?
>
> This way only those filesystems that need to encumber their semantics have to do so.
But this removes half of the point of having extended attributes ---
portability!
By specifying the attribute families explicitly, the application can
tell the filesystem what it is expecting, and all filesystems will
have available that information in a unified manner. An application
can use "ATR_USER" and get the lowest-common-denominator named
attribute semantics regardless of whether the underlying filesystem is
"encumbered" with streams too or not.
If you start inventing different naming conventions depending on what
_other_ features are being provided, rather than on what the user is
requesting, then access to the common features in a consistent manner
is impossible.
> > Yes, but most filesystems don't, and will not, support arbitrary
> > atomic operations. Heck, not even write(2) is atomic on any
> > filesystems I know of right now, since you can take a page fault
> > during the write as we copy the data from user space to the page cache
> > and another application can then see the partially complete write in
> > memory. (NB this is *completely* different from the atomic updates
> > we were talking about in Miami, which were concerned not with atomic
> > updates to cache but atomic updates to disk, which is where journal
> > transactions enter the picture.)
>
> why make it impossible for any fs to ever implement an atomic write?
Sorry --- I don't understand. Who is saying this? Certainly not me.
What I'm saying is that these are different problems. Making huge
atomic updates possible is a very, very different problem to
generating a decent attribute API. I'm trying to solve problem 2
without forcing all existing filesystems to fix problem 1 first,
because a lot of the existing filesystems *can't* fix problem 1.
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
