關於檔案寫入的原子性討論

jeff216發表於2017-08-07

​   檔案的寫入是否是原子的？多個執行緒寫入同一個檔案是否會寫錯亂?多個程式寫入同一個檔案是否會寫錯亂？想必這些問題多多少少會對我們產生一定的困擾，即使知道結果，很多時候也很難將這其中的原理清晰的表達給提問者，侯捷曾說過，原始碼面前,了無祕密，那麼本文也希望從原始碼的角度分析上述問題。在開始之前我們需要補充一下Linux 檔案相關的一些基礎原理，便於更好的看懂Linux原始碼。

​   學過Linux的讀者想必都應該知道檔案的資料分為兩個部分，一個部分就是檔案資料本身，另外一個部分則是檔案的後設資料，也就是inode、許可權、擴充套件屬性、mtime、ctime、atime等等，inode對於一個檔案來說及其的重要，可以唯一的標識一個檔案(實際應該是inode + dev號，唯一標識一個檔案，更準確來說應該是在同一個檔案系統的前提下才成立，不同的檔案系統inode是會重複的，不過這不是重點，姑且這裡不嚴謹的認為inode就是用來唯一標識一個檔案的吧)，核心中將inode號和檔案的後設資料構建為一個struct inode物件，該物件結構如下:

struct inode {
    umode_t            i_mode;
    uid_t            i_uid;
    gid_t            i_gid;
    unsigned long        i_ino;
    atomic_t        i_count;
    dev_t            i_rdev;
    loff_t            i_size;
    struct timespec        i_atime;
    struct timespec        i_mtime;
    struct timespec        i_ctime;
    .......// 省略
};

​   通過這個inode物件就可以關聯一個檔案，然後對這個檔案進行讀寫操作，Linux核心對於檔案同樣也有一個struct file物件來表示，該物件結構如下:

struct file {
      .....
    const struct file_operations    *f_op;
    loff_t            f_pos;
    struct address_space    *f_mapping;
     ....// 省略
};

​   有幾個成員比較關鍵，一個是f_op，檔案操作的方法集合，檔案操作不用關心其底層的檔案系統是什麼，直接通過f_op成員找到對應的方法即可。另外一個則是f_pos，也就是這個檔案讀到哪裡了，或者說是寫到哪裡了，是一個偏移量。一個程式開啟一個檔案的時候就會在核心中建立一個struct file物件，讀取檔案的時候則分為以下幾步:

  1. 通過fd找到對應對應的struct file物件
  2. 通過struct file物件獲取當前的offset，也就是讀取f_pos成員
  3. 通過f_op找到對應的操作方法，並傳入要讀取的偏移量進行資料的讀取
  4. 讀取完成後，重新設定新的offset

一次讀檔案的過程便是如此，對應到程式碼也是非常的清晰，如下:

// vfs_read -> do_sync_read
ssize_t do_sync_read(struct file *filp, char __user *buf, size_t len, loff_t *ppos)
{
    struct iovec iov = { .iov_base = buf, .iov_len = len };
    struct kiocb kiocb;
    ssize_t ret;
    // 設定要讀取的長度和開始的偏移量
    init_sync_kiocb(&kiocb, filp);
    kiocb.ki_pos = *ppos;
    kiocb.ki_left = len;
    kiocb.ki_nbytes = len;

    for (;;) {
        // 實際開始進行讀取操作
        ret = filp->f_op->aio_read(&kiocb, &iov, 1, kiocb.ki_pos);
        if (ret != -EIOCBRETRY)
            break;
        wait_on_retry_sync_kiocb(&kiocb);
    }

    if (-EIOCBQUEUED == ret)
        ret = wait_on_sync_kiocb(&kiocb);
    // 讀完後更新最後的offset
    *ppos = kiocb.ki_pos;
    return ret;
}

​   檔案的寫入也是如此，拿到offet，呼叫實際的寫入方法，最後更新offset。到此為止一個檔案的讀和寫的大體過程我們是清楚了，很顯然上述的過程並不是原子的，無論是檔案的讀還是寫，都至少有兩個步驟，一個是拿offset，另外一個則是實際的讀和寫。並且在整個過程中並沒有看到加鎖的動作，那麼第一個問題就得到了解決。對於第二個問題我們可以簡要的分析下，假如有兩個執行緒，第一個執行緒拿到offset是1，然後開始寫入，在寫入的過程中，第二個執行緒也去拿offset，因為對於一個檔案來說多個執行緒是共享同一個struct file結構，因此拿到的offset仍然是1，這個時候執行緒1寫結束，更新offset，然後執行緒2開始寫。最後的結果顯而易見，執行緒2覆蓋了執行緒1的資料，通過分析可知，多執行緒寫檔案不是原子的，會產生資料覆蓋。但是否會產生資料錯亂，也就是資料交叉寫入了?其實這種情況是不會發生的，至於為什麼請看下面這段程式碼:

ssize_t generic_file_aio_write(struct kiocb *iocb, const struct iovec *iov,
        unsigned long nr_segs, loff_t pos)
{
    struct file *file = iocb->ki_filp;
    struct inode *inode = file->f_mapping->host;
    struct blk_plug plug;
    ssize_t ret;

    BUG_ON(iocb->ki_pos != pos);
    // 檔案的寫入其實是加鎖的
    mutex_lock(&inode->i_mutex);
    blk_start_plug(&plug);
    ret = __generic_file_aio_write(iocb, iov, nr_segs, &iocb->ki_pos);
    mutex_unlock(&inode->i_mutex);

    if (ret > 0 || ret == -EIOCBQUEUED) {
        ssize_t err;

        err = generic_write_sync(file, pos, ret);
        if (err < 0 && ret > 0)
            ret = err;
    }
    blk_finish_plug(&plug);
    return ret;
}
EXPORT_SYMBOL(generic_file_aio_write);

​   所以並不會產生資料錯亂，只會存在資料覆蓋的問題，既然如此我們在實際的進行檔案讀寫的時候是否需要進行加鎖呢? 加鎖的確是可以解決問題的，但是在這裡未免有點牛刀殺雞的感覺，好在OS給我們提供了原子寫入的方法，第一種就是在開啟檔案的時候新增O_APPEND標誌，通過O_APPEND標誌將獲取檔案的offset和檔案寫入放在一起用鎖進行了保護，使得這兩步是原子的，具體程式碼可以看上面程式碼中的__generic_file_aio_write函式。


ssize_t __generic_file_aio_write(struct kiocb *iocb, const struct iovec *iov,
                 unsigned long nr_segs, loff_t *ppos)
{
    struct file *file = iocb->ki_filp;
    struct address_space * mapping = file->f_mapping;
    size_t ocount;        /* original count */
    size_t count;        /* after file limit checks */
    struct inode     *inode = mapping->host;
    loff_t        pos;
    ssize_t        written;
    ssize_t        err;

    ocount = 0;
    err = generic_segment_checks(iov, &nr_segs, &ocount, VERIFY_READ);
    if (err)
        return err;

    count = ocount;
    pos = *ppos;

    vfs_check_frozen(inode->i_sb, SB_FREEZE_WRITE);

    /* We can write back this queue in page reclaim */
    current->backing_dev_info = mapping->backing_dev_info;
    written = 0;
    // 重點就在這個函式
    err = generic_write_checks(file, &pos, &count, S_ISBLK(inode->i_mode));
    if (err)
        goto out;
    ......// 省略
}

inline int generic_write_checks(struct file *file, loff_t *pos, size_t *count, int isblk)
{
    struct inode *inode = file->f_mapping->host;
    unsigned long limit = rlimit(RLIMIT_FSIZE);

        if (unlikely(*pos < 0))
                return -EINVAL;

    if (!isblk) {
        /* FIXME: this is for backwards compatibility with 2.4 */
          // 如果帶有O_APPEND標誌，會直接拿到檔案的大小，設定為新的offset
        if (file->f_flags & O_APPEND)
                        *pos = i_size_read(inode);

        if (limit != RLIM_INFINITY) {
            if (*pos >= limit) {
                send_sig(SIGXFSZ, current, 0);
                return -EFBIG;
            }
            if (*count > limit - (typeof(limit))*pos) {
                *count = limit - (typeof(limit))*pos;
            }
        }
    }
    ......// 省略
}

​   通過上面的程式碼可知，如果帶有O_APPEND標誌的情況，在檔案真正寫入之前會呼叫generic_write_checks進行一些檢查，在檢查的時候如果發現帶有O_APPEND標誌就將offset設定為檔案的大小。而這整個過程都是在加鎖的情況下完成的，所以帶有O_APPEND標誌的情況下，檔案的寫入是原子的，多執行緒寫檔案是不會導致資料錯亂的。另外一種情況就是pwrite系統呼叫，pwrite系統呼叫通過讓使用者指定寫入的offset，值得整個寫入的過程天然的變成原子的了，在上文說到，整個寫入的過程是因為獲取offset和檔案寫入是兩個獨立的步驟，並沒有加鎖，通過pwrite省去了獲取offset這一步，最終整個檔案寫入只有一步加鎖的檔案寫入過程了。pwrite的程式碼如下:

SYSCALL_DEFINE(pwrite64)(unsigned int fd, const char __user *buf,
             size_t count, loff_t pos)
{
    struct file *file;
    ssize_t ret = -EBADF;
    int fput_needed;

    if (pos < 0)
        return -EINVAL;

    file = fget_light(fd, &fput_needed);
    if (file) {
        ret = -ESPIPE;
        if (file->f_mode & FMODE_PWRITE)  
            // 直接把offset也就是pos傳遞進去，而普通的write需要
            // 需要先從struct file中拿到offset，然後傳遞進去
            ret = vfs_write(file, buf, count, &pos);
        fput_light(file, fput_needed);
    }

    return ret;
}

SYSCALL_DEFINE3(write, unsigned int, fd, const char __user *, buf,
        size_t, count)
{
    struct file *file;
    ssize_t ret = -EBADF;
    int fput_needed;

    file = fget_light(fd, &fput_needed);
    if (file) {
        // 第一步拿offset
        loff_t pos = file_pos_read(file);
        // 第二步實際的寫入
        ret = vfs_write(file, buf, count, &pos);
        // 第三步寫回offset
        file_pos_write(file, pos);
        fput_light(file, fput_needed);
    }

    return ret;
}

​   最後一個問題是多個程式寫同一個檔案是否會造成檔案寫錯亂，直觀來說是多程式寫檔案不是原子的，這是很顯而易見的，因為每個程式都擁有一個struct file物件，是獨立的，並且都擁有獨立的檔案offset，所以很顯然這會導致上文中說到的資料覆蓋的情況，但是否會導致資料錯亂呢?，答案是不會，雖然struct file物件是獨立的，但是struct inode是共享的(相同的檔案無論開啟多少次都只有一個struct inode物件)，檔案的最後寫入其實是先要寫入到頁快取中，而頁快取和struct inode是一一對應的關係，在實際檔案寫入之前會加鎖，而這個鎖就是屬於struct inode物件(見上文中的mutex_lock(&inode->i_mutex))的，所有無論有多少個程式或者執行緒，只要是對同一個檔案寫資料，拿到的都是同一把鎖，是執行緒安全的，所以也不會出現資料寫錯亂的情況。


相關文章