On Sun, 2013-10-27 at 12:48 +0000, Myklebust, Trond wrote: > Let's get the basic discussion of motivation right first. Actually I might know another use case. dCache[0] which implements a (p)NFS 4.1 server and is heavily used within the high energy physics community, could benefit from XATTRs as well. Ever since, dCache has had a concept called PNFS tags (where the PNFS had nothing to do with parallel NFS, but is called so for other historical reasons), which are basically key/value pairs belonging to some file (well at least directory, I don't remember where PNFS tags exist for regular files). These tags are used to control several things, indirectly, e.g. to which data pool node a file may go, and via that whether it may be moved to tape, whether it is duplicated, etc. pp. Since there were no XATTRs (at least I guess that's the historical reason), they used special files for this having the name: ".(tag)(key)" and the content of the file is the value. So for a path, /data/foo/bar/ one can set the key "sGroup" (aka storage group) to a value say "ATLAS" (which (very simplified) will tell dCache in the end that this is storage belonging to the ATLAS experiment) by creating a file echo "ATLAS" > '/data/foo/bar/.(tag)(sGroup)' Obviously having such special files isn't that nice, and having real XATTRs would be the better solution. Cheers, Chris. btw: Note that while I'm good friends with the dCache developers, I don't speak for them, nor do I know whether they'd really like this or not. [0] http://www.dcache.org/ -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html