Quoted:
"at this time, there are still 1086911 extent nodes in this zombie
extent tree that need to be cleaned up.
crash_arm64_sprd_v8.0.3++> extent_tree.node_cnt ff80896cc500
node_cnt = {
counter = 1086911
},
"
As reported by Xiuhong, there will be a huge number of extent nodes
in ex
We use rwlock to protect core structure data of extent tree during
its shrink, however, if there is a huge number of extent nodes in
extent tree, during shrink of extent tree, it may hold rwlock for
a very long time, which may trigger kernel hang issue.
This patch fixes to shrink read extent node
On 2024/11/22 13:23, Zhiguo Niu wrote:
Chao Yu via Linux-f2fs-devel
于2024年11月21日周四 10:01写道：
Quoted:
"at this time, there are still 1086911 extent nodes in this zombie
extent tree that need to be cleaned up.
crash_arm64_sprd_v8.0.3++> extent_tree.node_cnt ff80896cc500
node_cnt = {
Chao Yu via Linux-f2fs-devel
于2024年11月21日周四 10:01写道：
>
> Quoted:
> "at this time, there are still 1086911 extent nodes in this zombie
> extent tree that need to be cleaned up.
>
> crash_arm64_sprd_v8.0.3++> extent_tree.node_cnt ff80896cc500
> node_cnt = {
> counter = 1086911
> },
> "
>
On 11/21, Eric Sandeen wrote:
> On 11/20/24 2:38 PM, Jaegeuk Kim wrote:
> > On 11/20, Eric Sandeen wrote:
>
> ...
>
> >> (Note that f2fs is the only filesystem that attempts to handle lazytime
> >> within
> >> the filesystem itself):
> >>
> >> [linux]# grep -r \"lazytime\" fs/*/
> >> fs/f2fs/sup
Hello:
This patch was applied to jaegeuk/f2fs.git (dev)
by Jaegeuk Kim :
On Mon, 18 Nov 2024 10:45:35 -0800 you wrote:
> From: Daeho Jeong
>
> The unusable cap value must be adjusted before checking whether
> checkpoint=disable is feasible.
>
> Signed-off-by: Daeho Jeong
>
> [...]
Here is t
Hello:
This series was applied to jaegeuk/f2fs.git (dev)
by Jaegeuk Kim :
On Fri, 8 Nov 2024 09:25:54 +0800 you wrote:
> It missed to cast variable to unsigned long long type before
> bit shift, which will cause overflow, fix it.
>
> Fixes: f7ef9b83b583 ("f2fs: introduce macros to convert bytes
Hello:
This patch was applied to jaegeuk/f2fs.git (dev)
by Jaegeuk Kim :
On Sun, 17 Nov 2024 23:01:40 -0800 you wrote:
> strcpy is deprecated. Kernel docs recommend replacing strcpy with
> strscpy. The function strcpy() return value isn't used so there
> shouldn't be an issue replacing with the s
Hello:
This series was applied to jaegeuk/f2fs.git (dev)
by Jaegeuk Kim :
On Thu, 21 Nov 2024 16:26:56 +0800 you wrote:
> Fsync data recovery attempts to check and fix write pointer consistency
> of cursegs and all other zones. If the write pointers of cursegs are
> unaligned, cursegs are changed
Hello:
This patch was applied to jaegeuk/f2fs.git (dev)
by Jaegeuk Kim :
On Thu, 7 Nov 2024 09:46:02 +0800 you wrote:
> f2fs doesn't support different blksize in one instance, so
> bytes_to_blks() and blks_to_bytes() are equal to F2FS_BYTES_TO_BLK
> and F2FS_BLK_TO_BYTES, let's use F2FS_BYTES_TO
Hello:
The following patches were marked "accepted", because they were applied to
jaegeuk/f2fs.git (dev):
Series: [f2fs-dev,1/4] f2fs: fix to do cast in F2FS_{BLK_TO_BYTES,
BTYES_TO_BLK} to avoid overflow
Submitter: Chao Yu
Patchwork: https://patchwork.kernel.org/project/f2fs/list/?series=9
On 11/20/24 2:38 PM, Jaegeuk Kim wrote:
> On 11/20, Eric Sandeen wrote:
...
>> (Note that f2fs is the only filesystem that attempts to handle lazytime
>> within
>> the filesystem itself):
>>
>> [linux]# grep -r \"lazytime\" fs/*/
>> fs/f2fs/super.c: {Opt_lazytime, "lazytime"},
>> [linux]#
>>
Some drives operate in "512e" configuration with their logical block
size set to 512 bytes for legacy compatibility reasons while providing
a more optimal 4096 byte value as the physical block size.
Since the physical block size is the smallest unit a physical storage
device can write atomically,
Piergiorgio reported a bug in bugzilla as below:
[ cut here ]
WARNING: CPU: 2 PID: 969 at fs/f2fs/segment.c:1330
RIP: 0010:__submit_discard_cmd+0x27d/0x400 [f2fs]
Call Trace:
__issue_discard_cmd+0x1ca/0x350 [f2fs]
issue_discard_thread+0x191/0x480 [f2fs]
kthread+0xcf/0x10
https://bugzilla.kernel.org/show_bug.cgi?id=219484
--- Comment #7 from Chao Yu (c...@kernel.org) ---
(In reply to piergiorgio.sartor from comment #3)
> One more thing, possibly important.
>
> When I create the snapshot, with the working kernel, while
> "max_discard_segments" is still "1", the oth
https://bugzilla.kernel.org/show_bug.cgi?id=219484
--- Comment #6 from Chao Yu (c...@kernel.org) ---
Sorry for long delay due to I'm out of office.
Now, I can reproduce this bug w/ below testcase:
- pvcreate /dev/vdb
- vgcreate myvg1 /dev/vdb
- lvcreate -L 1024m -n mylv1 myvg1
- mount /dev/myvg1/
On 2024/11/21 16:26, Sheng Yong wrote:
Fsync data recovery attempts to check and fix write pointer consistency
of cursegs and all other zones. If the write pointers of cursegs are
unaligned, cursegs are changed to new sections.
If recovery fails, zone write pointers are still checked and fixed,
Fsync data recovery attempts to check and fix write pointer consistency
of cursegs and all other zones. If the write pointers of cursegs are
unaligned, cursegs are changed to new sections.
If recovery fails, zone write pointers are still checked and fixed,
but the latest checkpoint cannot be writt
SBI_POR_DOING can be cleared after recovery is completed, so that
changes made before recovery can be persistent, and subsequent
errors can be recorded into cp/sb.
Signed-off-by: Song Feng
Signed-off-by: Yongpeng Yang
Signed-off-by: Sheng Yong
Reviewed-by: Chao Yu
---
fs/f2fs/super.c | 6 +++-
19 matches
Mail list logo
