自研文件系統本身通用功能要達到那些標準才算通用呢？

01-21

希望能有具體一點的答案。

如果自研文件系統的目的是通用，那麼首先要確定通用的標準。一般來說，自研文件系統與主流文件系統差異越小越通用。在確定這個前提條件下，看看哪些是主流文件系統呢？一個文件系統要是主流那必須擁有大規模的使用檢測，這裡舉兩個例子：Google的Colossus（GFS2）目前底層的文件系統已經升級到了ext4，也就是說ext4經受住了Google EB級數據的檢驗；Facebook的Haystack底層文件系統目前採用的是SGI研發的XFS，目前Facebook大概600PB的圖片數據完全由XFS存儲。

為什麼Google和Facebook要採用ext4或者XFS呢？除了他們出色性能以外，另一個重要的原因是他們都是符合POSIX語義的。換句話說，他們完全符合POSIX關於文件的所有操作定義。因此一個文件系統要做到儘可能地通用，就要儘可能得符合POSIX語義，因為POSIX本身就是為了通用而定義的。

POSIX語義關於文件操作的定義至少包括以下：

struct file_operations {

struct module *owner;

loff_t (*llseek) (struct file *, loff_t, int);

ssize_t (*read) (struct file *, char *, size_t, loff_t *);

ssize_t (*write) (struct file *, const char *, size_t, loff_t *);

int (*readdir) (struct file *, void *, filldir_t);

unsigned int (*poll) (struct file *, struct poll_table_struct *);

int (*ioctl) (struct inode *, struct file *, unsigned int, unsigned long);

int (*mmap) (struct file *, struct vm_area_struct *);

int (*open) (struct inode *, struct file *);

int (*flush) (struct file *);

int (*release) (struct inode *, struct file *);

int (*fsync) (struct file *, struct dentry *, int datasync);

int (*fasync) (int, struct file *, int);

int (*lock) (struct file *, int, struct file_lock *);

ssize_t (*readv) (struct file *, const struct iovec *, unsigned long, loff_t *);

ssize_t (*writev) (struct file *, const struct iovec *, unsigned long, loff_t *);

ssize_t (*sendpage) (struct file *, struct page *, int, size_t, loff_t *, int);

unsigned long (*get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long);

};

上面這些操作僅僅是關於文件操作的，另外還與關於元數據操作的，這裡就不再列出來了，具體可以查看Linux系統頭文件fs.h的的定義。

分散式文件系統如果要通用，也意味著要符合所有這些POSIX定義的語義。這裡也需要指出，對於特定的文件系統尤其是自研分散式文件系統，通用往往不是其最重要的功能，甚至根本不是其設計要求，例如Google的GFS和Facebook的Haystack，都不是通用文件系統，都不符合POSIX語義，但是都很好地解決了自身業務的挑戰。

所以，自研文件系統個人認為最重要的不一定是通用，而應該更多地考慮如何解決自身業務的問題。

應該沒有一個獨立的"通用文件系統"標準，而是屬於POSIX（POSIX.1-2008：The Open Group Base Specifications Issue 7, 2013 Edition）的一部分，實現POSIX定義的介面集合即可（readdir等，前面鏈接左側"System Interface"可查）。

Linux VFS是符合POSIX標準的，因此自研文件系統參照VFS即可。

POSIX標準滿足度的測試工具：

fstest（POSIX Test Suite）
PCTS（Test Suites）

剛聽完Larry Greenfield關於Colossus的talk，回來答題。基本贊成 @嚴林的回答。或者，我們把「通用」定義成C程序移植到你的文件系統的代價，也可以整理成如下幾個層次：

1. 完全符合POSIX或兼容其大部分。因為POSIX是對syscall的描述，所以你的文件系統需要提供規定好的syscall的實現。以Linux為例，開發一個基於VFS的文件系統，那麼它可以替代比如ext4而不需要程序作出任何修改。就像你不同分區mount了不同的文件系統，程序跑在哪裡都無所謂。這應該說是最「通用」的一種方式了。另外，如果想在user space實現主要邏輯的話，可以基於FUSE開發。

2. 參照POSIX語義實現，但需要提供特殊的lib供一般程序使用。出於某種原因，也許你想拋開POSIX、VFS和FUSE的限制，那麼你完全可以實現自己的一套。但程序沒有辦法繼續使用glibc來與你的文件系統交互，而需要使用你提供的library。當然，為了「通用」，你的lib可以保持與傳統介面或模型的相似性，從而程序可以保持絕大部分業務邏輯不變，可以比較容易地重寫，以使用你的新library。這樣的實現也算比較通用吧。Google FS、HDFS基本屬於此類，它們部分支持傳統文件系統模型（比如directory），但你需要特定的lib去訪問。

3. 自己根據業務設計文件系統介面，未必支持一般程序的需求。這就是最自由，但是通用性最低的方式。它們不以兼容POSIX為目標，而是根據上層業務需要來設計介面。你的遺留代碼通常沒有辦法直接移植。具體的例子包括提供MPI-IO介面的PVFS（及其v2），和傳統的POSIX介面有本質不同。既然是自由設計，那麼相應地，很難有一個題主所期待的「標準」來說它是否通用；相對而言，如果符合「小眾」標準（例如MPI-IO），意味著會在一定範圍內更通用。