I/O versus no I/O

Because Pnfs was designed to distribute a namespace, regular I/O operations had to be disabled in some way. The only meaningful NFS2 returncode which could indicate this behaviour is NFS_IO_ERROR. This nfs error code is returned whenever a read or write access is performed on a fileentry which is not enabled for I/O. On the other hand it would be nice to have the possibility to have regular files in the filesystem for steering and informational purposes.( Config files behind a wormhole or README files in some user directories.) There are two ways to manipulate the I/O behaviour of a file.

I/O behaviour by 'export' options

The third item in the pnfs exports files in /pnfs/fs/admin/etc/exports/<hostIP> is an integer decribing the I/O behaviour of the particular mountpoint. The 30 is the standard option for hosts which should mainly see the I/O disabled filesystem. The 0 is the standard option for hosts which have to do administrative tasks. The former disallows I/O at all, which is not very usefull when reading from configurationfiles behind a wormhole. To bypass this restriction a special attribute can be assigned per file.

I/O behaviour by 'I/O enabled' flags

A file can be I/O enabled individually. This attribute doesn't change its behaviour when the filesystem is mounted with 0 but when mounted with 30 the file behaves like a regular file. All files in directories which are expected to be behind wormholes have to be set I/O enabled individually. Otherwise a 30-exported filesystem is not able to read from this file. The attribute I/O enabled disappears of course together with the file after its removal.

How to set the I/O enable bit 
touch .(fset)(<filename>)(io)
sets the I/O enable flag for the file <filename>. The file has to exist before. The attribute stays with the file as long as the file is not removed or the attribute is resetted. 
rm .(fset)(<filename>)(io)
removes the I/O enabled attribute again. The removal of the 'I/O enabled' flag is not yet implemented in Pnfs 3.1.2.