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
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 or write datas into segment x;
6) sudden
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
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 matched. So just skip to flush NAT bits in
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 segment x;
> 4) write checkpoint B;
> 5) issue
On 2018/2/5 14:40, Yunlong Song wrote:
> Is it necessary to make atomic commit fail? What's the problem of this
> patch (no lock at all and does not make atomic fail)? These two patches
> aims to provide ability to gc old blocks of opened atomic file, with no
> affection to original atomic commit
Is it necessary to make atomic commit fail? What's the problem of this
patch (no lock at all and does not make atomic fail)? These two patches
aims to provide ability to gc old blocks of opened atomic file, with no
affection to original atomic commit and no mix with inmem pages.
On 2018/2/5
On 2018/2/5 10:53, Yunlong Song wrote:
> Is it necessary to add a lock here? What's the problem of this patch (no
> lock at all)? Anyway, the problem is expected to be fixed asap, since
> attackers can easily write an app with only atomic start and no atomic
> commit, which will cause f2fs run
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.
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 matched. So just skip to flush NAT bits in such
needless cases.
Signed-off-by: Weichao
Is it necessary to add a lock here? What's the problem of this patch (no
lock at all)? Anyway, the problem is expected to be fixed asap, since
attackers can easily write an app with only atomic start and no atomic
commit, which will cause f2fs run into loop gc if the disk layout is
much
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 or write datas into segment x;
6) sudden
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/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 in segment x;
> 4) write checkpoint B;
> 5) issue
Well, that's classic algorithm for checking loop in a list, as well as
other one we know, in order to decrease time complexity of these algorithms,
their implementations are a little more complex.
But IMO, the issue we are trying to fix is really a corner case, and the
performance in that path is
On 2018/2/3 10:47, Yunlong Song wrote:
> If inode has already started to atomic commit, then set_page_dirty will
> not mix the gc pages with the inmem atomic pages, so the page can be
> gced safely.
Let's avoid Ccing fs mailing list if the patch didn't change vfs common
codes.
As you know, the
Hi,
On 2018/2/3 1:29, Piergiorgio Sartor wrote:
> Hi all,
>
> I'm planning to prepare a Linux installation
> on an USB flash drive.
>
> The idea is to have /boot (with ext, since grub2
> does not support f2fs yet) and / with f2fs.
> Both on the USB flash drive while /home will be
> somewhere
17 matches
Mail list logo
