On 03/21/2016 02:11 PM, Richard Yao wrote: > I am thinking of implementing Solaris-style alternative data streams in > the ZFSOnLinux driver via an ioctl and writing a compatibility shim so > that software written to use O_XATTR can be trivially adapted to use the > interface. > > I sketched out the fine details on github: > > https://github.com/zfsonlinux/zfs/issues/4437 > > I would be much happier if the VFS gave filesystem drivers the ability > to implement O_XATTR. That would avoid the need to (ab)use an ioctl for > this and eliminate the risk of using a bit that would be defined to mean > something else. The former risks permissions checks becoming stale while > the latter is a situation that I would be happy to avoid. > > Since this sort of interface is applicable to NFS too, I wanted to ask > what various mainline developers think about it before I tried doing an > initial implementation. > 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. Alternative data streams are in the NFSv4 specification, so I thought that the developers of the NFS client driver would want something like this. If it went into the VFS, then existing in-tree filesystems could have it mapped to the existing interface, which would allow it to work everywhere extended attributes are implemented. If they are not interested, then I could go ahead with my ioctl idea. I just wanted to try to implement this in a way everyone who can use it would like so that we can avoid a XKCD #927 situation in the future: https://xkcd.com/927/
Attachment:
signature.asc
Description: OpenPGP digital signature
