Re: Making an interface for alternative data streams

[Dave Chinner <david@fromorbit.com>]

On Mon, Mar 21, 2016 at 10:01:35PM -0400, Richard Yao wrote:
> 
> > On Mar 21, 2016, at 4:40 PM, J. Bruce Fields
> > <bfields@fieldses.org> wrote:
> > 
> >> On Mon, Mar 21, 2016 at 04:19:17PM -0400, Richard Yao wrote:
> >> Maybe I should clarify that the idea is to allow
> >> read/write/list of extended attributes via read/write/readdir
> >> so that those that want extended attributes that are
> >> alternative data streams can have them. I do not want to see
> >> extended attributes and alternative data streams be different
> >> things.
> > 
> > I think there are differences between the two that make this
> > awkward.  Does anyone actually use alternative data stream for
> > anything that makes the effort worthwhile?
> 
> For particularly large extended attributes, avoiding having to
> read the entire value into userspace, modify it and write it back
> is nice. I believe that XFS goes up to 64KB.

Sorry, but XFS xattrs are cannot be partially overwritten due to the
write atomicity requirement of xattrs (i.e. either the entire change
or none of the change is present after a crash). not to mention that
we'd have to completely re-implement extended attributes in XFS to
support them being used as ADS. That's simply not going to happen.

Extended attributes are *not data streams*. Stop trying to make them
data streams - the APIs and the implementations in the fileystems
are simply not designed to be used as seekable data streams.

If you want additional seekable data streams, then come up with a
filesystem namespace method of addressing these alternate data
streams as *separate files containing data*. That's all an ADS is -
a namespace hack to address multiple data files through a single
file name. That's the problem that needs solving and it has nothing
to do with xattrs.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com