You are making extended attributes different from files in more than name. This is
deeply and
fundamentally wrong.
"Stephen C. Tweedie" wrote:
>
> 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?
/process/buffer/(X,Y,Z)<=/name_of_file_or_attribute_of_unknown_size
will write into Z the number of bytes written, with the write starting at X and not
going past Y
>
> > > 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
then don't misfeature atomicity in! If you can't do it right, don't code it into VFS
so that we all
get stuck with it!
> impossible to implement arbitrary transactions over filesystems such
> as NFS, but we still need ACL APIs for that.
So don't make atomic a filesystem that doesn't support atomicity. Why do you want to
do that? What
is even crazier is that you blame me for this requirement of yours which is supposedly
a requirement
of mine. If it doesn't support atomicity it ignores the atomicity specification by
the user, if it
requires atomicity it imposes it on the user, if it is well designed it does as asked,
what is the
problem?
You have some misdesigned filesystems you want to support by forcing all the rest of
the filesystems
to be misdesigned. Make misdesign optional not mandatory. That means don't give us a
single way of
doing things that combines several different features in a non-orthogonalized way that
forces us to
take all features when we only want one of them.
Otherwise Linux will always be inferior to BeOS in the filesystems department, and
when MS ships
their next FS we may be inferior to that (they are adding database features I hear).
>
> > > 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]
