"Stephen C. Tweedie" wrote:
>
> 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.
filename/stream/foo and filename/attribute/FOO
?
This way only those filesystems that need to encumber their semantics have to do so.
>
> 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.)
why make it impossible for any fs to ever implement an atomic write?
>
> 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]
