Does thes make sense?
https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git/commit/?h=dev-test=608460dfae20b9d23aa222f7448710a086778222
https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git/commit/?h=dev-test=962379487b5cb9f3b85ea367b130c2c6ca584edf
Second one is needed to
https://bugzilla.kernel.org/show_bug.cgi?id=216050
--- Comment #85 from Guido (guido.iod...@gmail.com) ---
I modified the script to run it on the partition on my choice. No problem with
the home and other partitions. It looks like something in root partition. May
be it is related to the bug?
--
On Sat, Nov 12, 2022 at 12:15:08AM +, 'Nick Terrell' via syzkaller-bugs
wrote:
>
> Not quite sure why I am CC'd here, I don't see anything related to zstd or
> compression in this stack.
> Just want to check that it is likely unrelated, and that I'm not missing
> something.
>
> Best,
>
> On Nov 7, 2022, at 4:15 PM, syzbot
> wrote:
>
> !---|
> This Message Is From an External Sender
>
> |---!
>
> syzbot has found a reproducer for the following
https://bugzilla.kernel.org/show_bug.cgi?id=216050
--- Comment #83 from Guido (guido.iod...@gmail.com) ---
I tried this script to trigger the GC:
https://github.com/LLJY/f2fs-gc/blob/master/f2fs-gc.sh
It's been running for 10 minutes now, but it's stock to 2503 dirty segments on
the root
https://bugzilla.kernel.org/show_bug.cgi?id=216050
--- Comment #84 from Guido (guido.iod...@gmail.com) ---
this is the output
Performing GC on /sys/fs/f2fs/nvme0n1p3/
2589
2589
2503
2503
2503
2503
...
and a lot of 2503
--
You may reply to this email to add a comment.
You are receiving
https://bugzilla.kernel.org/show_bug.cgi?id=216050
--- Comment #80 from Guido (guido.iod...@gmail.com) ---
(In reply to Jaegeuk Kim from comment #79)
I tried to apply it to kernel 6.0.8 but failed. I found the code at row 1313 so
I can try to apply there. But there is another identical code at
On 2022/11/11 18:08, Sheng Yong wrote:
If compress_extension is set, and a newly created file matches the
extension, the file could be marked as compression file. However,
if inline_data is also enabled, there is no chance to check its
extension since f2fs_should_compress() always returns false.
On 2022/11/11 18:08, Sheng Yong wrote:
Since the file name has already passed to f2fs_new_inode(), let's
move set_file_temperature() into f2fs_new_inode().
Signed-off-by: Sheng Yong
Reviewed-by: Chao Yu
Thanks,
___
Linux-f2fs-devel mailing list
On Fri, Nov 11, 2022, at 10:40, Zhiguo Niu wrote:
> Arnd Bergmann 于2022年11月10日周四 21:45写道：
> I thinks the gcc complier build warning :
>
> In file included from fs/f2fs/segment.c:24:
>>> fs/f2fs/gc.h:73:1: warning: alignment 1
Since the file name has already passed to f2fs_new_inode(), let's
move set_file_temperature() into f2fs_new_inode().
Signed-off-by: Sheng Yong
---
fs/f2fs/namei.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
index
If compress_extension is set, and a newly created file matches the
extension, the file could be marked as compression file. However,
if inline_data is also enabled, there is no chance to check its
extension since f2fs_should_compress() always returns false.
This patch moves set_compress_inode(),
This patch adds a new proc entry to show discard_plist
information in more detail, which is very helpful to
know the discard pend list count clearly.
Such as:
Discard pending list(Show diacrd command count on each entry):
04943 138 66 29 21
From: Daeho Jeong
introduce a new ioctl to replace the whole content of a file atomically,
which means it induces truncate and content update at the same time.
We can start it with F2FS_IOC_START_ATOMIC_REPLACE and complete it with
F2FS_IOC_COMMIT_ATOMIC_WRITE. Or abort it with
Complaint from Matthew Wilcox in another similar place:
"submit? You don't submit anything at the 'submit' label.
it should be called 'skip' or something. But I think this
is just badly written and you don't need a goto at all."
Let's remove submit label for
https://bugzilla.kernel.org/show_bug.cgi?id=216050
--- Comment #82 from Guido (guido.iod...@gmail.com) ---
(In reply to Jaegeuk Kim from comment #81)
> I think 1313 would be enough to avoid this issue first.
> 3568 case is after submit IO which could have a chance to get another states.
Thank
https://bugzilla.kernel.org/show_bug.cgi?id=216050
--- Comment #81 from Jaegeuk Kim (jaeg...@kernel.org) ---
I think 1313 would be enough to avoid this issue first.
3568 case is after submit IO which could have a chance to get another states.
--
You may reply to this email to add a comment.
17 matches
Mail list logo
