Hi,
On Wed, Oct 25, 2000 at 03:52:34PM -0700, Hans Reiser wrote:
> > There already exist filesystems where named streams and named atomic
> > attributes both already exist. We need to differentiate between them.
>
> Why? Just constrain the stream I/O for atomic attributes to be an error unless the
>I/O overwrites
> the entire I/O.
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.
We need a rich enough namespace to be able to access both.
> > There already exist attributes which cannot be made into a stream,
> > because we simply don't have access to the raw bits of the attribute
> > --- for example, ACLs on networked filesystems.
> You are restricting the general case to serve the special case.
Yes --- this is intended to be specifically an attribute API, not to
serve the needs of a multi-streamed file. Both problems need
addressed. It would be just as bad if we only implemented the general
solution and ignored the special requirements of the attributes here.
> Make atomicity an orthogonal
> restriction. There are apps which would like to atomically update arbitrary file
>bodies not just
> file attributes..... by making atomicity an orthogonal feature applicable to both
>file bodies and
> file attributes you gain. Yes?
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.)
I still want these other filesystems to be able to support attributes
sanely. There's no reason to try to do everything with one API if the
special cases hurt so much that you just end up overengineering to
cover every case.
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
