Hi,
On Wed, Oct 25, 2000 at 05:48:54PM -0700, Hans Reiser wrote:
> > Also, your proposed API is _too_ flexible to be useful for atomic
> > guarantees --- there's just no way you can say "transfer this several
> > GB of file stream into that buffer there" and expect to have it
> > atomic!
>
> Do you need reads into user space to be atomic, or do you need writes into kernel
>space to be
> atomic. I think you only need the writes into kernel space to be atomic, yes?
>Define your atomic
> needs more precisely if you can.
For ACLs, it's quite simple:
* if a write is in progress, all accesses to the ACL string must
reflect either the entire state of the ACL before the modification was
made, or the entire state after ALL of the component parts of the
modification have been applied; and
* A set-and-get operation must not allow any other writes between the
get and the set; and
* once the ACL set is complete, no new read must ever return the old value
of the ACL.
So writes are atomic with respect to other reads and writes, and
writes act as a barrier.
> > For distributed filesystems, there may well be no atomic operation on
> > ACLs at all other than small, well-defined ones. Over-engineer the
> > interface and you lose all the elegance for no gain, because the
> > application just can't use the fancy bells and whistles without losing
> > the atomicity guarantees.
>
> Maybe we should just let the filesystem decide which operations on which objects to
>do atomically if
> they are in the same syscall whether asked or not, which ones not to do atomically
>at all even if
> asked, and which to do atomically if asked to. Do you agree with that?
Letting the filesystem do things atomically without being asked to is
fine, because that obviously never breaks the user's requested
semantics. Your API so far doesn't let the user request the semantics
explicitly, though.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
