On Oct 27, 2013, at 8:14 PM, Christoph Anton Mitterer <calestyo@xxxxxxxxxxxx> wrote: > 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. Ordinary groups can do the same. Trond-- 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
