Hi,
On Wed, Oct 25, 2000 at 09:52:28AM -0700, Hans Reiser wrote:
> > However, that breaks for GETALL, where the application is giving the
> > kernel a large buffer into which an unknown number of attributes may
> > be written.
>
> That is why I use a sequence of assignment statements in my proposal for a syntax.
>That allows you
> to leave in place the data, and assign multiple file contents to multiple locations
>in the process
> address space, or use a file descriptor to access the contents, as the user chooses.
How would this work for reading an unknown amount of attribute data
into a single application buffer at once? How would the application
parse the return data?
> > We _could_ specify different data layouts for set and get, but that's
> > ugly.
> >
> > > Why do you treat attributes differently from files? Why is your interface
>specific to attributes
> > > rather than files generally with attributes being files with a particular name?
> >
> > Atomic updates.
>
> You are saying we need a transaction syntax with a transaction start and a
>transaction end operator
> pair, yes? Let's stop being inferior to databases..... this is something new, let's
>do it right.
I am *not* going to implement database-style transactions just for
something which is basically an extended chmod()! It is also quite
impossible to implement arbitrary transactions over filesystems such
as NFS, but we still need ACL APIs for that.
> > There are existing filesystems which have completely separate
> > namespaces for block-attributes and for named streams. Named streams
> > have proper file semantics, but block attributes do not --- they have
> > a fixed maximum size and are read/written in one single go.
>
> So you need an EINCOMPLETE_IO or some such, yes? procfs has the same problem, let's
>solve it
> orthogonally to this discussion.
Please, let's make large bulk transfers and large transactions
orthogonal to the discussion. Most filesystems will never support
those. We still need extended attribute and ACL APIs.
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
