Commit 089842de ("f2fs: remove codes of unused wio_mutex") removes codes
of unused wio_mutex, but missing the comment, so delete it.
Signed-off-by: Yunlong Song
---
fs/f2fs/f2fs.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 7cec897..03e7
v1->v2: delete comments in f2fs.h: "/* bio ordering for NODE/DATA */"
Signed-off-by: Yunlong Song
Reviewed-by: Chao Yu
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/f2fs.h | 2 --
fs/f2fs/super.c | 5 +
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/fs/f2fs/f2f
when the whole section is invalid, which can issue discard
aligned to section size as much as possible and avoid redundant discard.
Signed-off-by: Yunlong Song
Signed-off-by: Chao Yu
---
fs/f2fs/segment.c | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
diff
when the whole section is invalid, which can issue discard
aligned to section size as much as possible and avoid redundant discard.
Signed-off-by: Yunlong Song
Signed-off-by: Chao Yu
---
fs/f2fs/segment.c | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
diff
to change zone_align_start_offset to u64, because
zone_align_start_offset is always
smaller than zone_size_bytes, which is u32.
Thanks,
Junling
On 2018/5/26 16:09, Yunlong Song wrote:
zone_align_start_offset should be u64, but config.start_sector is u32,
so it may be overflow when computing
to change zone_align_start_offset to u64, because
zone_align_start_offset is always
smaller than zone_size_bytes, which is u32.
Thanks,
Junling
On 2018/5/26 16:09, Yunlong Song wrote:
zone_align_start_offset should be u64, but config.start_sector is u32,
so it may be overflow when computing
ping...
On 2018/5/7 10:15, Yunlong Song wrote:
f2fs-tools uses ioctl BLKSSZGET to get sector_size, however, this ioctl
will return a value which may be larger than 512 (according to the value
of q->limits.logical_block_size), then this will be inconsistent with
the start_sector, si
ping...
On 2018/5/7 10:15, Yunlong Song wrote:
f2fs-tools uses ioctl BLKSSZGET to get sector_size, however, this ioctl
will return a value which may be larger than 512 (according to the value
of q->limits.logical_block_size), then this will be inconsistent with
the start_sector, si
zone_align_start_offset should be u64, but config.start_sector is u32,
so it may be overflow when computing zone_align_start_offset.
Signed-off-by: Yunlong Song <yunlong.s...@huawei.com>
---
fsck/resize.c | 7 ---
mkfs/f2fs_format.c | 4 ++--
2 files changed, 6 insertions
zone_align_start_offset should be u64, but config.start_sector is u32,
so it may be overflow when computing zone_align_start_offset.
Signed-off-by: Yunlong Song
---
fsck/resize.c | 7 ---
mkfs/f2fs_format.c | 4 ++--
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/fsck
ays in 512 size unit for a sector. To fix this problem, just
change the sector_size to the default value when computing with
start_sector. And fix sectors_per_blk as well.
Signed-off-by: Yunlong Song <yunlong.s...@huawei.com>
---
fsck/resize.c | 4 ++--
mkfs/f2fs_format.c | 12 ++
ays in 512 size unit for a sector. To fix this problem, just
change the sector_size to the default value when computing with
start_sector. And fix sectors_per_blk as well.
Signed-off-by: Yunlong Song
---
fsck/resize.c | 4 ++--
mkfs/f2fs_format.c | 12 ++--
2 files changed, 8 inserti
ays in 512 size unit for a sector. To fix this problem, just set
the sector_size to the default value 512.
Signed-off-by: Yunlong Song <yunlong.s...@huawei.com>
---
lib/libf2fs.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/lib/libf2fs.c b/lib/libf2fs.c
index 102e579..e160f
ays in 512 size unit for a sector. To fix this problem, just set
the sector_size to the default value 512.
Signed-off-by: Yunlong Song
---
lib/libf2fs.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/lib/libf2fs.c b/lib/libf2fs.c
index 102e579..e160f2a 100644
--- a/lib/libf2fs.c
+++ b/
Please avoid this patch, I make a mistake.
On 2018/5/3 15:45, Yunlong Song wrote:
Commit 6f890df0 ("f2fs: fix out-of-order execution in f2fs_issue_flush")
uses waitqueue_active to wake up issue_flush thread, but there is no
wait entry to wake in this queue, so change it back to use th
Please avoid this patch, I make a mistake.
On 2018/5/3 15:45, Yunlong Song wrote:
Commit 6f890df0 ("f2fs: fix out-of-order execution in f2fs_issue_flush")
uses waitqueue_active to wake up issue_flush thread, but there is no
wait entry to wake in this queue, so change it back to use th
Commit 6f890df0 ("f2fs: fix out-of-order execution in f2fs_issue_flush")
uses waitqueue_active to wake up issue_flush thread, but there is no
wait entry to wake in this queue, so change it back to use the original
fcc->dispatch_list to wake up issue_flush thread.
Signed-off-by:
Commit 6f890df0 ("f2fs: fix out-of-order execution in f2fs_issue_flush")
uses waitqueue_active to wake up issue_flush thread, but there is no
wait entry to wake in this queue, so change it back to use the original
fcc->dispatch_list to wake up issue_flush thread.
Signed-off-by:
the
zero_user_segment is OK.
Signed-off-by: Yunlong Song <yunlong.s...@huawei.com>
---
fs/f2fs/inline.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/f2fs/inline.c b/fs/f2fs/inline.c
index 3b77d64..573ec2f 100644
--- a/fs/f2fs/inline.c
+++ b/fs/f2fs/inline.c
@@ -367,7 +367,6 @@ stat
the
zero_user_segment is OK.
Signed-off-by: Yunlong Song
---
fs/f2fs/inline.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/f2fs/inline.c b/fs/f2fs/inline.c
index 3b77d64..573ec2f 100644
--- a/fs/f2fs/inline.c
+++ b/fs/f2fs/inline.c
@@ -367,7 +367,6 @@ static int f2fs_move_inline_dirents(struct inode *dir
In make_dentry_ptr_block, it is confused with "&" for t->dentry_bitmap
but without "&" for t->dentry, so delete "&" to make code more readable.
Signed-off-by: Yunlong Song <yunlong.s...@huawei.com>
---
fs/f2fs/f2fs.h | 2 +-
1 file change
In make_dentry_ptr_block, it is confused with "&" for t->dentry_bitmap
but without "&" for t->dentry, so delete "&" to make code more readable.
Signed-off-by: Yunlong Song
---
fs/f2fs/f2fs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
Since f2fs_inode_info is allocated with flag GFP_F2FS_ZERO, so we do not
need to initialize zero value for its member any more.
Signed-off-by: Yunlong Song <yunlong.s...@huawei.com>
---
fs/f2fs/super.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/fs/f2fs/super.c b/fs/f2fs/s
Since f2fs_inode_info is allocated with flag GFP_F2FS_ZERO, so we do not
need to initialize zero value for its member any more.
Signed-off-by: Yunlong Song
---
fs/f2fs/super.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 0c1fe9b..42d564c 100644
Since f2fs_inode_info is allocated with flag GFP_F2FS_ZERO, so we do not
need to initialize zero value for its member any more.
Signed-off-by: Yunlong Song <yunlong.s...@huawei.com>
---
fs/f2fs/super.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/fs/f2fs/super.c b/fs/f2fs/s
Since f2fs_inode_info is allocated with flag GFP_F2FS_ZERO, so we do not
need to initialize zero value for its member any more.
Signed-off-by: Yunlong Song
---
fs/f2fs/super.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 0c1fe9b..3a7fa03
OK, got it.
On 2018/3/19 14:23, Jaegeuk Kim wrote:
On 03/19, Yunlong Song wrote:
Hi, Jaegeuk,
I find this patch is removed from current branch of dev-test
recently, why? Any bugs?
Moved into the beginning of the tree for cherry-picking into f2fs-stable.
Thanks,
On 2018/2/28 20:31
OK, got it.
On 2018/3/19 14:23, Jaegeuk Kim wrote:
On 03/19, Yunlong Song wrote:
Hi, Jaegeuk,
I find this patch is removed from current branch of dev-test
recently, why? Any bugs?
Moved into the beginning of the tree for cherry-picking into f2fs-stable.
Thanks,
On 2018/2/28 20:31
Hi, Jaegeuk,
I find this patch is removed from current branch of dev-test
recently, why? Any bugs?
On 2018/2/28 20:31, Yunlong Song wrote:
Previous dentry page uses highmem, which will cause panic in platforms
using highmem (such as arm), since the address space of dentry pages
from highmem
Hi, Jaegeuk,
I find this patch is removed from current branch of dev-test
recently, why? Any bugs?
On 2018/2/28 20:31, Yunlong Song wrote:
Previous dentry page uses highmem, which will cause panic in platforms
using highmem (such as arm), since the address space of dentry pages
from highmem
On 2018/2/28 13:48, Jaegeuk Kim wrote:
Hi Yunlong,
As Eric pointed out, how do you think using nohighmem for directory likewise
ext4, which looks like more efficient?
OK, I have sent out another patch like this.
Actually, we don't need to do this in
most of recent kernels, right?
Why? I
On 2018/2/28 13:48, Jaegeuk Kim wrote:
Hi Yunlong,
As Eric pointed out, how do you think using nohighmem for directory likewise
ext4, which looks like more efficient?
OK, I have sent out another patch like this.
Actually, we don't need to do this in
most of recent kernels, right?
Why? I
, and then cause panic since it doesn't call kmap_high but
kunmap_high is triggered at the end. To fix this problem in a simple
way, this patch avoids to put dentry page in pagecache into highmem.
Signed-off-by: Yunlong Song <yunlong.s...@huawei.com>
---
fs/f2fs/dir.c
, and then cause panic since it doesn't call kmap_high but
kunmap_high is triggered at the end. To fix this problem in a simple
way, this patch avoids to put dentry page in pagecache into highmem.
Signed-off-by: Yunlong Song
---
fs/f2fs/dir.c | 23 +--
fs/f2fs/f2fs.h
Howerver, later patch:
commit e06f86e61d7a ("f2fs crypto: avoid unneeded memory allocation in
->readdir")
reverts the codes, which causes panic again in arm, so fix it back to the old
version.
Signed-off-by: Yunlong Song <yunlong.s...@huawei.com>
Reviewed-by: Chao Yu <yuch..
Howerver, later patch:
commit e06f86e61d7a ("f2fs crypto: avoid unneeded memory allocation in
->readdir")
reverts the codes, which causes panic again in arm, so fix it back to the old
version.
Signed-off-by: Yunlong Song
Reviewed-by: Chao Yu
---
fs/f2fs/dir.c | 7 +++
1 fil
avoid
unneeded memory allocation in ->readdir")
reverts the codes, which causes panic again in arm, so let's add part of
the old patch again for dentry page.
Signed-off-by: Yunlong Song <yunlong.s...@huawei.com>
---
fs/f2fs/dir.c | 7 +++
1 file changed, 7 insertions(+)
diff --
avoid
unneeded memory allocation in ->readdir")
reverts the codes, which causes panic again in arm, so let's add part of
the old patch again for dentry page.
Signed-off-by: Yunlong Song
---
fs/f2fs/dir.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
, Eric Biggers wrote:
Hi Yunlong,
On Sat, Feb 24, 2018 at 05:14:58PM +0800, Yunlong Song wrote:
In some platforms (such as arm), high memory is used, then the
decrypting filename will cause panic, the reason see commit
569cf1876a32e574ba8a7fb825cd91bafd003882 ("f2fs crypto: allocate b
, Eric Biggers wrote:
Hi Yunlong,
On Sat, Feb 24, 2018 at 05:14:58PM +0800, Yunlong Song wrote:
In some platforms (such as arm), high memory is used, then the
decrypting filename will cause panic, the reason see commit
569cf1876a32e574ba8a7fb825cd91bafd003882 ("f2fs crypto: allocate b
avoid
unneeded memory allocation in ->readdir")
reverts the codes, which causes panic again in arm, so let's add part of
the old patch again for dentry page.
Signed-off-by: Yunlong Song <yunlong.s...@huawei.com>
---
fs/f2fs/dir.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/
avoid
unneeded memory allocation in ->readdir")
reverts the codes, which causes panic again in arm, so let's add part of
the old patch again for dentry page.
Signed-off-by: Yunlong Song
---
fs/f2fs/dir.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
avoid
unneeded memory allocation when {en/de}crypting symlink")
commit e06f86e61d7a67fe6e826010f57aa39c674f4b1b ("f2fs crypto: avoid
unneeded memory allocation in ->readdir")
reverts the codes, which causes panic again in arm, so let's add the old
patch again.
Signed-off-by: Yunl
avoid
unneeded memory allocation when {en/de}crypting symlink")
commit e06f86e61d7a67fe6e826010f57aa39c674f4b1b ("f2fs crypto: avoid
unneeded memory allocation in ->readdir")
reverts the codes, which causes panic again in arm, so let's add the old
patch again.
Signed-off-by: Yunlon
OK, Got it.
On 2018/2/11 11:50, Chao Yu wrote:
On 2018/2/11 11:34, Yunlong Song wrote:
Ping...
move_data_block misses set_cold_data, then the F2FS_WB_CP_DATA will
lack these data pages in move_data_block, and write_checkpoint can
not make sure this pages committed to the flash.
Hmm.. data
OK, Got it.
On 2018/2/11 11:50, Chao Yu wrote:
On 2018/2/11 11:34, Yunlong Song wrote:
Ping...
move_data_block misses set_cold_data, then the F2FS_WB_CP_DATA will
lack these data pages in move_data_block, and write_checkpoint can
not make sure this pages committed to the flash.
Hmm.. data
Ping...
move_data_block misses set_cold_data, then the F2FS_WB_CP_DATA will
lack these data pages in move_data_block, and write_checkpoint can
not make sure this pages committed to the flash.
On 2018/2/8 20:33, Yunlong Song wrote:
Signed-off-by: Yunlong Song <yunlong.s...@huawei.com>
--
Ping...
move_data_block misses set_cold_data, then the F2FS_WB_CP_DATA will
lack these data pages in move_data_block, and write_checkpoint can
not make sure this pages committed to the flash.
On 2018/2/8 20:33, Yunlong Song wrote:
Signed-off-by: Yunlong Song
---
fs/f2fs/gc.c | 1 +
1 file
that it has run time out, and should
handle the inmem pages
Back to these two patches, why not use them to separate inmem pages
and GCed data pages in such a simple way.
On 2018/2/9 21:38, Chao Yu wrote:
On 2018/2/9 21:29, Yunlong Song wrote:
Back to the problem, if we skip out
that it has run time out, and should
handle the inmem pages
Back to these two patches, why not use them to separate inmem pages
and GCed data pages in such a simple way.
On 2018/2/9 21:38, Chao Yu wrote:
On 2018/2/9 21:29, Yunlong Song wrote:
Back to the problem, if we skip out
Back to the problem, if we skip out, then the f2fs_gc will go
into dead loop if the apps only atomic start but never atomic
commit. The main aim of my two patches is to remove the skip
action to avoid the dead loop.
On 2018/2/9 21:26, Chao Yu wrote:
On 2018/2/9 20:56, Yunlong Song wrote
Back to the problem, if we skip out, then the f2fs_gc will go
into dead loop if the apps only atomic start but never atomic
commit. The main aim of my two patches is to remove the skip
action to avoid the dead loop.
On 2018/2/9 21:26, Chao Yu wrote:
On 2018/2/9 20:56, Yunlong Song wrote
ter __commit_inmem_pages->do_write_data_page.
On 2018/2/9 20:44, Chao Yu wrote:
On 2018/2/8 11:11, Yunlong Song wrote:
Then the GCed data pages are totally mixed with the inmem atomic pages,
If we add dio_rwsem, GC flow is exclude with atomic write flow. There
will be not race case to mix GCed page into
ter __commit_inmem_pages->do_write_data_page.
On 2018/2/9 20:44, Chao Yu wrote:
On 2018/2/8 11:11, Yunlong Song wrote:
Then the GCed data pages are totally mixed with the inmem atomic pages,
If we add dio_rwsem, GC flow is exclude with atomic write flow. There
will be not race case to mix GCed page into
Signed-off-by: Yunlong Song <yunlong.s...@huawei.com>
---
fs/f2fs/gc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index b9d93fd..2095630 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -692,6 +692,7 @@ static void move_data_block(struct inode *inode, b
Signed-off-by: Yunlong Song
---
fs/f2fs/gc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index b9d93fd..2095630 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -692,6 +692,7 @@ static void move_data_block(struct inode *inode, block_t
bidx,
fio.op
of this patch to fix the
dnode page problem (dnode page commited but data page are not committed
for the GCed page)?
On 2018/2/7 20:16, Chao Yu wrote:
On 2018/2/6 11:49, Yunlong Song wrote:
This patch adds fi->commit_lock to avoid the case that GCed node pages
are committed but GCed data pa
of this patch to fix the
dnode page problem (dnode page commited but data page are not committed
for the GCed page)?
On 2018/2/7 20:16, Chao Yu wrote:
On 2018/2/6 11:49, Yunlong Song wrote:
This patch adds fi->commit_lock to avoid the case that GCed node pages
are committed but GCed data pa
This patch adds fi->commit_lock to avoid the case that GCed node pages
are committed but GCed data pages are not committed. This can avoid the
db file run into inconsistent state when sudden-power-off happens if
data pages of atomic file is allowed to be GCed before.
Signed-off-by: Yunlong S
This patch adds fi->commit_lock to avoid the case that GCed node pages
are committed but GCed data pages are not committed. This can avoid the
db file run into inconsistent state when sudden-power-off happens if
data pages of atomic file is allowed to be GCed before.
Signed-off-by: Yunlong S
. These patches and the locks can make sure the GCed data
pages are all committed to nand flash with their nodes.
On 2018/2/5 19:10, Chao Yu wrote:
On 2018/2/5 17:37, Yunlong Song wrote:
OK, details as I explained before:
atomic_commit GC
- file_write_and_wait_range
. These patches and the locks can make sure the GCed data
pages are all committed to nand flash with their nodes.
On 2018/2/5 19:10, Chao Yu wrote:
On 2018/2/5 17:37, Yunlong Song wrote:
OK, details as I explained before:
atomic_commit GC
- file_write_and_wait_range
E] during atomic committing to exclude
GCing data block of atomic opened file?
Thanks,
Signed-off-by: Yunlong Song <yunlong.s...@huawei.com>
---
fs/f2fs/data.c | 5 ++---
fs/f2fs/gc.c | 6 --
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2f
E] during atomic committing to exclude
GCing data block of atomic opened file?
Thanks,
Signed-off-by: Yunlong Song
---
fs/f2fs/data.c | 5 ++---
fs/f2fs/gc.c | 6 --
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 7435830..edafcb6
:29, Chao Yu wrote:
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
:29, Chao Yu wrote:
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
will block all the fs ops (all the fs ops
will hang up in f2fs_balance_fs).
On 2018/2/4 22:56, Chao Yu wrote:
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
will block all the fs ops (all the fs ops
will hang up in f2fs_balance_fs).
On 2018/2/4 22:56, Chao Yu wrote:
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
This patch enables to gc atomic file by adding GC_WRITTEN_PAGE to
identify the gced pages of atomic file, which can avoid
register_inmem_page in set_page_dirty, so the gced pages will not mix
with the inmem pages.
Signed-off-by: Yunlong Song <yunlong.s...@huawei.com>
---
fs/f2fs/data.c
This patch enables to gc atomic file by adding GC_WRITTEN_PAGE to
identify the gced pages of atomic file, which can avoid
register_inmem_page in set_page_dirty, so the gced pages will not mix
with the inmem pages.
Signed-off-by: Yunlong Song
---
fs/f2fs/data.c| 7 ++-
fs/f2fs/gc.c
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.
Signed-off-by: Yunlong Song <yunlong.s...@huawei.com>
---
fs/f2fs/data.c | 5 ++---
fs/f2fs/gc.c | 6 --
2 files changed, 6 inse
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.
Signed-off-by: Yunlong Song
---
fs/f2fs/data.c | 5 ++---
fs/f2fs/gc.c | 6 --
2 files changed, 6 insertions(+), 5 deletions(-)
diff
29 11:37, Yunlong Song wrote:
Commit 7a20b8a61eff81bdb7097a578752a74860e9d142 ("f2fs: allocate node
and hot data in the beginning of partition") introduces another mount
option, heap, to reset it back. But it does not do anything for heap
mode, so fix it.
I think Jaegeuk did three things in
29 11:37, Yunlong Song wrote:
Commit 7a20b8a61eff81bdb7097a578752a74860e9d142 ("f2fs: allocate node
and hot data in the beginning of partition") introduces another mount
option, heap, to reset it back. But it does not do anything for heap
mode, so fix it.
I think Jaegeuk did three things in
Commit 7a20b8a61eff81bdb7097a578752a74860e9d142 ("f2fs: allocate node
and hot data in the beginning of partition") introduces another mount
option, heap, to reset it back. But it does not do anything for heap
mode, so fix it.
Signed-off-by: Yunlong Song <yunlong.s...@huawei.com>
-
Commit 7a20b8a61eff81bdb7097a578752a74860e9d142 ("f2fs: allocate node
and hot data in the beginning of partition") introduces another mount
option, heap, to reset it back. But it does not do anything for heap
mode, so fix it.
Signed-off-by: Yunlong Song
---
fs/f2fs/gc.c | 5 +++-
t;old_addr, ni.version, true, true);
f2fs_put_dnode();
}
--
Thanks,
Yunlong Song
f2fs_put_dnode();
}
--
Thanks,
Yunlong Song
k_count > sbi->user_block_count)) {
spin_unlock(>stat_lock);
goto enospc;
}
--
Thanks,
Yunlong Song
k_count > sbi->user_block_count)) {
spin_unlock(>stat_lock);
goto enospc;
}
--
Thanks,
Yunlong Song
sbi->current_reserved_blocks;
+ buf->f_bavail = buf->f_bfree;
avail_node_count = sbi->total_node_count - sbi->nquota_files -
F2FS_RESERVED_NODE_NUM;
--
Thanks,
Yunlong Song
>current_reserved_blocks;
+ buf->f_bavail = buf->f_bfree;
avail_node_count = sbi->total_node_count - sbi->nquota_files -
F2FS_RESERVED_NODE_NUM;
--
Thanks,
Yunlong Song
the
update_sit_entry(sbi, new_blkaddr, 1) with no next_blkoff refresh, as a
result, when recovery process write checkpoint and sync nodes, the
next_blkoff of curseg is used in the segment bit map, then it will
cause f2fs_bug_on. So let's check segment type in __f2fs_replace_block.
Signed-off-by: Yunlong Song
the
update_sit_entry(sbi, new_blkaddr, 1) with no next_blkoff refresh, as a
result, when recovery process write checkpoint and sync nodes, the
next_blkoff of curseg is used in the segment bit map, then it will
cause f2fs_bug_on. So let's check segment type in __f2fs_replace_block.
Signed-off-by: Yunlong Song
---
fs
the
update_sit_entry(sbi, new_blkaddr, 1) with no next_blkoff refresh, as a
result, when recovery process write checkpoint and sync nodes, the
next_blkoff of curseg is used in the segment bit map, then it will
cause f2fs_bug_on. So let's check segment type in __f2fs_replace_block.
Signed-off-by: Yunlong Song
the
update_sit_entry(sbi, new_blkaddr, 1) with no next_blkoff refresh, as a
result, when recovery process write checkpoint and sync nodes, the
next_blkoff of curseg is used in the segment bit map, then it will
cause f2fs_bug_on. So let's check segment type in __f2fs_replace_block.
Signed-off-by: Yunlong Song
---
fs
Signed-off-by: Yunlong Song <yunlong.s...@huawei.com>
---
fs/f2fs/segment.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 890d483..e3bbabf 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -2719,6 +2719,8 @@ void __f2fs_replace
Signed-off-by: Yunlong Song
---
fs/f2fs/segment.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 890d483..e3bbabf 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -2719,6 +2719,8 @@ void __f2fs_replace_block(struct f2fs_sb_info *sbi
On 2018/1/2 14:49, Chao Yu wrote:
On 2017/12/30 15:42, Yunlong Song wrote:
In some case, the node blocks has wrong blkaddr whose segment type is
You mean *data block* has wrong blkaddr whose segment type is NODE?
Yes.
NODE, e.g., recover inode has missing xattr flag and the blkaddr
On 2018/1/2 14:49, Chao Yu wrote:
On 2017/12/30 15:42, Yunlong Song wrote:
In some case, the node blocks has wrong blkaddr whose segment type is
You mean *data block* has wrong blkaddr whose segment type is NODE?
Yes.
NODE, e.g., recover inode has missing xattr flag and the blkaddr
segment.
Signed-off-by: Yunlong Song <yunlong.s...@huawei.com>
---
fs/f2fs/recovery.c | 3 ++-
fs/f2fs/segment.h | 3 +++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index 7d63faf..e8fee4a 100644
--- a/fs/f2fs/recovery.c
+++ b/f
segment.
Signed-off-by: Yunlong Song
---
fs/f2fs/recovery.c | 3 ++-
fs/f2fs/segment.h | 3 +++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index 7d63faf..e8fee4a 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -478,7 +478,8
In this case, f2fs_gc will skip all the victims and return with no dead
loop. The atomic file will
use SSR to OPU, it‘s OK.
On 2017/12/25 17:45, Chao Yu wrote:
On 2017/12/25 14:15, Yunlong Song wrote:
What if the application starts atomic write but forgets to commit, e.g.
bugs in application
In this case, f2fs_gc will skip all the victims and return with no dead
loop. The atomic file will
use SSR to OPU, it‘s OK.
On 2017/12/25 17:45, Chao Yu wrote:
On 2017/12/25 14:15, Yunlong Song wrote:
What if the application starts atomic write but forgets to commit, e.g.
bugs in application
What if the application starts atomic write but forgets to commit, e.g.
bugs in application or the application
is a malicious software itself?
On 2017/12/25 11:44, Chao Yu wrote:
On 2017/12/23 21:09, Yunlong Song wrote:
For some corner case, f2fs_gc selects one target victim but cannot free
What if the application starts atomic write but forgets to commit, e.g.
bugs in application or the application
is a malicious software itself?
On 2017/12/25 11:44, Chao Yu wrote:
On 2017/12/23 21:09, Yunlong Song wrote:
For some corner case, f2fs_gc selects one target victim but cannot free
. This patch identifies the dead-loop segment, and skips
it in __get_victim next time.
Signed-off-by: Yunlong Song <yunlong.s...@huawei.com>
---
fs/f2fs/f2fs.h | 8
fs/f2fs/gc.c| 34 ++
fs/f2fs/super.c | 3 +++
3 files changed, 45 insertions(+)
. This patch identifies the dead-loop segment, and skips
it in __get_victim next time.
Signed-off-by: Yunlong Song
---
fs/f2fs/f2fs.h | 8
fs/f2fs/gc.c| 34 ++
fs/f2fs/super.c | 3 +++
3 files changed, 45 insertions(+)
diff --git a/fs/f2fs/f2fs.h b
And there is en[namelen] = '\0', should fix namelen to its right value.
On 2017/12/23 11:35, Chao Yu wrote:
On 2017/12/23 11:19, Yunlong Song wrote:
Double free problem:
Since ddr bit jump makes i_namelen a larger value (> 255)，when file is
not encrypted,
the convert_encrypted_name will mem
And there is en[namelen] = '\0', should fix namelen to its right value.
On 2017/12/23 11:35, Chao Yu wrote:
On 2017/12/23 11:19, Yunlong Song wrote:
Double free problem:
Since ddr bit jump makes i_namelen a larger value (> 255)，when file is
not encrypted,
the convert_encrypted_name will mem
1 - 100 of 716 matches
Mail list logo
