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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
