Hi Jaegeuk,
Is your test using a kernel include some unstable patches like "f2fs: guarantee
journalled quota data by checkpoint"?
I am planing to reproduce the problem with dev branch. Is that OK? Any hints
for reproducing?
Thank,
Weichao
On 2018/8/18 2:32, Jaegeuk Kim wrote:
> Hi Weichao,
>
On 2018/7/30 14:41, Chao Yu wrote:
> Hi Weichao,
>
> On 2018/7/30 18:46, Weichao Guo wrote:
>
> Could you check and adjust your server's date, it looks like we are receiving
> patch from future. ;)
>
Oh, I didn't notice that. It will not happen any more.
Thanks,
>> We may encounter both che
On 2018/7/26 19:52, Chao Yu wrote:
> On 2018/7/24 23:28, Weichao Guo wrote:
>> We may encounter both checkpoints invalid in such a case:
>> 1. write checkpoint A, B, C;
>> 2. sudden power-cut during write checkpoint D;
>> 3. fsck changes the total block count of checkpoint C;
>> 4. sudden power-
On 2018/3/13 16:49, Sahitya Tummala wrote:
> On Thu, Mar 08, 2018 at 05:10:40AM +0800, Weichao Guo wrote:
>> @@ -159,8 +162,12 @@ bool f2fs_inode_chksum_verify(struct f2fs_sb_info *sbi,
>> struct page *page)
>> struct f2fs_inode *ri;
>> __u32 provided, calculated;
>>
>> +#ifdef CONFI
On 2018/3/9 13:49, Chao Yu wrote:
> On 2018/3/9 5:31, Weichao Guo wrote:
>> Only enable in-memory inode checksum to protect metadata blocks
>> from in-memory scribbles when checking consistency, which has no
>> performance requirements.
>
> Signed-off-by?
Sorry for this mistake.
I will send a ne
Hi Chao,
On 2018/3/8 17:11, Chao Yu wrote:
> Hi Weichao,
>
> On 2018/3/8 15:56, guoweichao wrote:
>> Hi Chao,
>>
>> On 2018/3/8 14:15, Chao Yu wrote:
>>> On 2018/3/8 5:10, Weichao Guo wrote:
>>>> Only enable in-memory inode checksum to protect me
On 2018/2/28 17:58, Chao Yu wrote:
> On 2018/2/27 3:28, Weichao Guo wrote:
>> Enable in-memory inode checksum to protect metadata blocks
>> from in-memory scribbles only when checking consistency with
>> no performance requirements.
>>
>> Signed-off-by: Weichao Guo
>> ---
>> fs/f2fs/inode.c | 7
Hi Jaegeuk,
On 2018/2/28 12:57, Jaegeuk Kim wrote:
> On 02/26, 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 i
On 2018/2/13 2:03, Jaegeuk Kim wrote:
> On 02/12, guoweichao wrote:
>>
>>
>> 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/
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 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
>>>> c
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 in
On 2018/2/5 15:41, Chao Yu wrote:
> On 2018/2/5 18:18, 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 segme
On 2018/2/5 15:42, Chao Yu wrote:
> On 2018/2/5 22:30, Weichao Guo wrote:
>> NAT bits are saved at spare space in CP pack. Flushed NAT bits
>> may be overwritten by the CP pack if there is no enough space
>> for NAT bits. And NAT bits will be obsolesced at next mount time
>> if crc|cp_ver not mat
On 2018/2/5 22:30, Weichao Guo wrote:
> NAT bits are saved at spare space in CP pack. Flushed NAT bits
> may be overwritten by the CP pack if there is no enough space
> for NAT bits. And NAT bits will be obsolesced at next mount time
Sorry, there is a typo here. 'obsolesced' should be obsolete.
T
Hi Chao,
On 2018/2/4 23:16, Chao Yu wrote:
> On 2018/2/3 20:12, 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
On 2018/1/22 14:19, Chao Yu wrote:
> On 2018/1/22 10:40, guoweichao wrote:
>> Hi Chao,
>>
>> On 2018/1/21 10:34, Chao Yu wrote:
>>> Hi Weichao,
>>>
>>> On 2018/1/20 23:50, guoweichao wrote:
>>>> Hi Chao,
>>>>
>>>&
Hi Xiang,
On 2018/1/21 11:27, Gao Xiang wrote:
> Hi Weichao,
>
>
> On 2018/1/21 0:02, guoweichao wrote:
>> Hi Xiang,
>>
>> it's not related to SPOR. Just consider the case given by Chao Yu.
>>
>
> (It seems this email was not sent successfully,
Hi Chao,
On 2018/1/21 10:34, Chao Yu wrote:
> Hi Weichao,
>
> On 2018/1/20 23:50, guoweichao wrote:
>> Hi Chao,
>>
>> Yes, it is exactly what I mean.
>> It seems that F2FS has no responsibility to cover hardware problems.
>> However, file systems usually
A critical case is using the free segments as data segments which
are previously node segments to the old checkpoint. With fault injecting
of the newer CP pack, fsck can find errors when checking the sanity of nid.
On 2018/1/20 7:29, Weichao Guo wrote:
> Currently, we set prefree segments as free
On 2017/10/13 20:43, Chao Yu wrote:
>
> On 2017/10/14 0:59, Weichao Guo wrote:
>> Punching hole with a length which far larger than file size will cause
>> a long time looping in truncate_hole after lock_op, it can be
>> reproduced as the following:
>>
>> $ echo "abc" > file
>>
From: Weichao Guo
In FI_NO_PREALLOC cases, direct I/O path may allocate blocks for an
inode but keep its inline data flag. This inconsistency may trigger
vfs clear_inode nrpages bug_on when evicting the inode. We should
convert inline data first in this case.
Signed-off-by: Weichao Guo
---
fs/
Sorry, made some typos in this patch. Ignore it.
On 2017/9/29 22:25, guoweic...@huawei.com wrote:
> From: Weichao Guo
>
> In FI_NO_PREALLOC cases, direct I/O path may allocate blocks for an
> inode but keep its inline data flag. This inconsistency may trigger
> vfs clear_inode nrpages bug_on whe
From: Weichao Guo
In FI_NO_PREALLOC cases, direct I/O path may allocate blocks for an
inode but keep its inline data flag. This inconsistency may trigger
vfs clear_inode nrpages bug_on when evicting the inode. We should
convert inline data first in this case.
Signed-off-by: Weichao Guo
---
fs/
Sure, I will prepare another patch to fix this case.
On 2017/9/28 22:23, Chao Yu wrote:
> On 2017/9/29 5:47, guoweic...@huawei.com wrote:
>> From: Weichao Guo
>>
>> In FI_NO_PREALLOC cases, direct I/O path may allocate blocks for an inode but
>> keep its inline data flag. This inconsistency may t
Hi Jaegeuk,
I agree that stat info miss matching is not a big problem. But consistent stat
view is better I think.
I will give a new patch as you suggested.
Thanks,
Weichao
-邮件原件-
发件人: Jaegeuk Kim [mailto:jaeg...@kernel.org]
发送时间: 2017年5月10日 1:52
收件人: guoweichao
抄送: linux-f2fs-devel
Agree, I will send a new verison of this patch.
-邮件原件-
发件人: Chao Yu [mailto:c...@kernel.org]
发送时间: 2017年5月9日 23:26
收件人: guoweichao; jaeg...@kernel.org
抄送: linux-f2fs-devel@lists.sourceforge.net
主题: Re: [f2fs-dev] [PATCH] f2fs: make sure f2fs_gc returns consistent errno
On 2017/5/9 19:37
Hi Jaegeuk,
I regard no enough free sections as a precondition when talking about
BG_GC -> FG_GC. I mean that for both case a) and b) I mentioned has no enough
free sections implicitly.
On 2017/2/25 2:49, Jaegeuk Kim wrote:
> Hi Weichao,
>
> On 02/25, Weichao Guo wrote:
>> When turning to FG_GC
On 2016/9/19 22:48, Chao Yu wrote:
> On 2016/9/20 5:03, Weichao Guo wrote:
>> This patch improves the migration of dirty pages and allows migrating atomic
>> written pages that F2FS uses in Page Cache. Instead of the fallback releasing
>> page path, it provides better performance for memory compa
29 matches
Mail list logo