在看UBIFS开发文档的时候有提到过UBIFS不支持NFS（网络文件系统），但是我在网上搜了搜也没有找到原因。所以做嵌入式开发的小伙伴要注意了，别在编译linux内核的时候之选择了UBIFS文件系统，使用的时候想尝试NFS不成功但却找不到原因。看UBIFS源码的时候偶然看到了不支持的原因。
代码来源：linux-3.13.8/fs/ubifs/dir.c（331行）：
/*
* The classical Unix view for directory is that it is a linear array of
* (name, inode number) entries. Linux/VFS assumes this model as well.
* Particularly, 'readdir()' call wants us to return a directory entry offset
* which later may be used to continue 'readdir()'ing the directory or to
* 'seek()' to that specific direntry. Obviously UBIFS does not really fit this
* model because directory entries are identified by keys, which may collide.
*
* UBIFS uses directory entry hash value for directory offsets, so
* 'seekdir()'/'telldir()' may not always work because of possible key
* collisions. But UBIFS guarantees that consecutive 'readdir()' calls work
* properly by means of saving full directory entry name in the private field
* of the file description object.
*
* This means that UBIFS cannot support NFS which requires full
* 'seekdir()'/'telldir()' support.
*/
上边的文档解释的很明确了，翻译过来的大概意思就是：
传统的UNIX看到的目录是线性数组项（名字，inode号），linux/vfs也继承了这个模式。系统函数readdir()也希望底层的文件系统对应的函数能返回一个目录项的偏移量，以便于稍后继续使用readdir()读取目录或者使用seek()寻找到特定的目录项。显然，UBIFS不能很好的支持这个模式，因为UBIFS的目录项是通过关键字识别的，这样就造成了冲突。
UBIFS使用目录项hash关键字作为目录偏移量，由于不兼容因此就不能保证seekdir()/telldir()两个函数的正常工作。但是UBIFS能保证可以连续调用readdir()可以正常工作，因为其将完整的目录项名字保存于file对象描述符的private 域中。
这就意味着UBIFS不支持NFS文件系统，因为NFS基于的文件系统需要充分支持seekdir()/telldir()两个函数。