[f2fs-dev] [PATCH 2/2] f2fs: expose extension_list sysfs entry

From: Chao Yu This patch adds a sysfs entry 'extension_list' to support lookup/ add/delete item in extension list. Lookup: cat /sys/fs/f2fs//extentsion_list Add: echo 'extension' > /sys/fs/f2fs//extentsion_list Delete: echo '!extension' > /sys/fs/f2fs//extentsion_list

[f2fs-dev] [PATCH 1/2] f2fs: introduce sb_lock to make encrypt pwsalt update exclusive

From: Chao Yu f2fs_super_block.encrypt_pw_salt can be udpated and persisted concurrently, result in getting different pwsalt in separated threads, so let's introduce sb_lock to exclude concurrent accessers. Signed-off-by: Chao Yu --- fs/f2fs/f2fs.h |

Re: [f2fs-dev] [RFC PATCH 0/2] f2fs: introduce lost+found feature

On 02/11, Sheng Yong wrote: > Hi, Jaegeuk > > On 2018/2/10 10:50, Jaegeuk Kim wrote: > > On 02/06, Sheng Yong wrote: > > > This patchset introduces lost+found feature in f2fs. If the feature is > > > enabled, f2fs should avoid to encrypting root directory. > > > > In that case, we need to add

Re: [f2fs-dev] [PATCH v3] f2fs: report cp block corrupted

On 02/06, Weichao Guo wrote: > There is a potential inconsistent metadata case due to a cp block > crc invalid in the latest checkpoint caused by hardware issues: > 1) write nodes into segment x; > 2) write checkpoint A; > 3) remove nodes in segment x; > 4) write checkpoint B; > 5) issue discard

Re: [f2fs-dev] [PATCH v2] f2fs: introduce "strict_fsync" for posix standard fsync

On 02/11, Junling Zheng wrote: > Hi, Jaegeuk > > On 2018/2/10 8:44, Jaegeuk Kim wrote: > > On 02/02, Junling Zheng wrote: > >> Commit "0a007b97aad6"(f2fs: recover directory operations by fsync) > >> fixed xfstest generic/342 case, but it also increased the written > >> data and caused the

[f2fs-dev] [PATCH RFC] f2fs: introduce a method to make nat journal more fresh

This patch introduce a method to make nat journal more fresh: i. sort set list using entry # plus cp version difference (last modify set cp # and current cp #) ii. if meet with cache hit, update last modify cp # to current cp # Signed-off-by: Yunlei He --- fs/f2fs/f2fs.h |

Re: [f2fs-dev] [PATCH v3] f2fs: report cp block corrupted

On 02/12, guoweichao wrote: > Hi Jaegeuk, > > On 2018/2/12 7:32, Jaegeuk Kim wrote: > > On 02/06, Weichao Guo wrote: > >> There is a potential inconsistent metadata case due to a cp block > >> crc invalid in the latest checkpoint caused by hardware issues: > >> 1) write nodes into segment x; > >>

Re: [f2fs-dev] [PATCH v3] f2fs: report cp block corrupted

On 02/12, guoweichao wrote: > > > On 2018/2/12 10:32, Jaegeuk Kim wrote: > > On 02/12, guoweichao wrote: > >> Hi Jaegeuk, > >> > >> On 2018/2/12 7:32, Jaegeuk Kim wrote: > >>> On 02/06, Weichao Guo wrote: > There is a potential inconsistent metadata case due to a cp block > crc invalid

[f2fs-dev] [PATCH] f2fs: add bug on back during flush nat entries

This patch add two bug on check back during flush nat entries, nat_tree_lock will prevent race from node block allocation in write_begin. Signed-off-by: Yunlei He --- fs/f2fs/node.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/fs/f2fs/node.c

Re: [f2fs-dev] [PATCH v3] f2fs: report cp block corrupted

Hi Jaegeuk, On 2018/2/12 7:32, Jaegeuk Kim wrote: > On 02/06, Weichao Guo wrote: >> There is a potential inconsistent metadata case due to a cp block >> crc invalid in the latest checkpoint caused by hardware issues: >> 1) write nodes into segment x; >> 2) write checkpoint A; >> 3) remove nodes

Re: [f2fs-dev] [PATCH v3] f2fs: report cp block corrupted

On 2018/2/12 10:32, Jaegeuk Kim wrote: > On 02/12, guoweichao wrote: >> Hi Jaegeuk, >> >> On 2018/2/12 7:32, Jaegeuk Kim wrote: >>> On 02/06, Weichao Guo wrote: There is a potential inconsistent metadata case due to a cp block crc invalid in the latest checkpoint caused by hardware

Re: [f2fs-dev] [PATCH v3] f2fs: report cp block corrupted

On 2018/2/12 11:40, Jaegeuk Kim wrote: > On 02/12, guoweichao wrote: >> >> >> On 2018/2/12 10:32, Jaegeuk Kim wrote: >>> On 02/12, guoweichao wrote: Hi Jaegeuk, On 2018/2/12 7:32, Jaegeuk Kim wrote: > On 02/06, Weichao Guo wrote: >> There is a potential inconsistent