Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752296AbbLOFeB (ORCPT ); Tue, 15 Dec 2015 00:34:01 -0500 Received: from mailout2.samsung.com ([203.254.224.25]:59670 "EHLO mailout2.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750767AbbLOFeA (ORCPT ); Tue, 15 Dec 2015 00:34:00 -0500 X-AuditID: cbfee61a-f79266d000003652-0e-566fa646db2a From: Chao Yu To: Jaegeuk Kim Cc: linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org Subject: [PATCH 5/8] f2fs: support data flush in checkpoint Date: Tue, 15 Dec 2015 13:33:18 +0800 Message-id: <00f801d136fa$324a5070$96def150$@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AdE29i7bGhFTI9+eSEeo0oJ8hbTkBg== Content-language: zh-cn X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsVy+t9jQV23ZflhBpdXiVg8WT+L2eLSIneL y7vmsDkwe2xa1cnmsXvBZyaPz5vkApijuGxSUnMyy1KL9O0SuDIO7trJXnBdqGLKpJNsDYwb +LsYOTkkBEwkli7cxAxhi0lcuLeerYuRi0NIYBajRP//HVDOK0aJ9hmLwKrYBFQklnf8ZwKx RYDsQ4sus4PYzAIeEo0d31m7GDk4hAWsJbZ8swYJswioSkz4MZUFxOYVsJTovraNGcIWlPgx +R4LRKuWxPqdx5kgbHmJzWveQh2kILHj7GtGiFV6Ers+fYZaJS6x8cgtlgmMQFcijJqFZNQs JKNmIWlZwMiyilEitSC5oDgpPdcwL7Vcrzgxt7g0L10vOT93EyM4iJ9J7WA8uMv9EKMAB6MS D+8C5vwwIdbEsuLK3EOMEhzMSiK8C3qBQrwpiZVVqUX58UWlOanFhxilOViUxHlrL0WGCQmk J5akZqemFqQWwWSZODilGhi96riNDxw4a9qSZ7jw2xPP7k2s9Twrw2dPnrk0dd4ZBTG70Myl 05brtMYxWXp9f/zq2mzNGRKxsixZP99MvXh75757rt5xegpmOpECfOkO2bbFtXYhVizNTjVm t779DJ6xubXji/qWnKzlSa9M9/p8Ondnc5/Q3tdHToRtuXPn11MvnYN8a1qVWIozEg21mIuK EwEygNuDXgIAAA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2561 Lines: 80 Previously, when finishing a checkpoint, we only keep consistency of all fs meta info including meta inode, node inode, dentry page of directory inode, so, after a sudden power cut, f2fs can recover from last checkpoint with full directory structure. But during checkpoint, we didn't flush dirty pages of regular and symlink inode, so such dirty datas still in memory will be lost in that moment of power off. In order to reduce the chance of lost data, this patch tries to flush user data before starting a checkpoint. So user's data written between two checkpoint which may not be fsynced could be saved. Signed-off-by: Chao Yu --- fs/f2fs/checkpoint.c | 11 +++++++++++ fs/f2fs/f2fs.h | 5 +++++ 2 files changed, 16 insertions(+) diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c index f33c4d7..217571f 100644 --- a/fs/f2fs/checkpoint.c +++ b/fs/f2fs/checkpoint.c @@ -849,6 +849,17 @@ static int block_operations(struct f2fs_sb_info *sbi) blk_start_plug(&plug); +retry_flush_datas: + /* write all the dirty data pages */ + if (get_pages(sbi, F2FS_DIRTY_DATAS)) { + sync_dirty_inodes(sbi, FILE_INODE); + if (unlikely(f2fs_cp_error(sbi))) { + err = -EIO; + goto out; + } + goto retry_flush_datas; + } + retry_flush_dents: f2fs_lock_all(sbi); /* write all the dirty dentry pages */ diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h index d8bef3c..2477b2f5 100644 --- a/fs/f2fs/f2fs.h +++ b/fs/f2fs/f2fs.h @@ -648,6 +648,7 @@ struct f2fs_sm_info { enum count_type { F2FS_WRITEBACK, F2FS_DIRTY_DENTS, + F2FS_DIRTY_DATAS, F2FS_DIRTY_NODES, F2FS_DIRTY_META, F2FS_INMEM_PAGES, @@ -1068,6 +1069,8 @@ static inline void inode_inc_dirty_pages(struct inode *inode) atomic_inc(&F2FS_I(inode)->dirty_pages); if (S_ISDIR(inode->i_mode)) inc_page_count(F2FS_I_SB(inode), F2FS_DIRTY_DENTS); + else + inc_page_count(F2FS_I_SB(inode), F2FS_DIRTY_DATAS); } static inline void dec_page_count(struct f2fs_sb_info *sbi, int count_type) @@ -1085,6 +1088,8 @@ static inline void inode_dec_dirty_pages(struct inode *inode) if (S_ISDIR(inode->i_mode)) dec_page_count(F2FS_I_SB(inode), F2FS_DIRTY_DENTS); + else + dec_page_count(F2FS_I_SB(inode), F2FS_DIRTY_DATAS); } static inline int get_pages(struct f2fs_sb_info *sbi, int count_type) -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/