7;t reply via my resend patch. I misspelled f2fs's
>subsytem mail address in the original patch and I sincerely apologize for that.
>I already re-sent the series as
> "[f2fs-dev] [RESEND RFC PATCH 0/9] f2fs: Enable buffered read/write large
> folios support with extended iomap&q
lly used to get f2fs_iomap_folio_state.
It cannot be used to get f2fs's own fields used on compressed folios.
For the former, we return a null pointer to indicate that the current
folio does not hold an f2fs_iomap_folio_state. For the latter, we
directly BUG_ON.
Signed-off-by: Nanzhe Zhao
-
it
logical file offset and LBA length instead of block-unit cnt and
page idx in fio if we are to support BLOCK_SIZE > PAGE_SIZE.
Suggestions are appreciated.
Signed-off-by: Nanzhe Zhao
---
fs/f2fs/data.c | 16 ++--
fs/f2fs/f2fs.h | 2 ++
2 files changed, 12 insertions(+), 6 deletions(-
Since `folio_detach_f2fs_private` can handle all case for a
folio to free it's private date , intergrate it as a subtitute
for `folio_detach_private`.
Signed-off-by: Nanzhe Zhao
---
fs/f2fs/data.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/fs/f2fs/data.c b/fs/f2fs/d
-off-by: Nanzhe Zhao
---
fs/f2fs/data.c | 13 +++--
fs/f2fs/gc.c | 37 +++--
2 files changed, 30 insertions(+), 20 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index b7bef2a28c8e..5ecd08a3dd0b 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
introduces. Suggestions would be grateful.
Signed-off-by: Nanzhe Zhao
---
fs/f2fs/f2fs.h | 278 +++--
1 file changed, 225 insertions(+), 53 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 8df0443dd189..a14bef4dc394 100644
--- a/fs/f2
ng
`f2fs_map_blocks` to preallocate blocks.
Signed-off-by: Nanzhe Zhao
---
fs/f2fs/data.c | 49 +++--
fs/f2fs/f2fs.h | 5 +
2 files changed, 48 insertions(+), 6 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 5ecd08a3dd0b
`f2fs_is_compressed_page` now already accept a folio as
a parameter.So the name now is confusing.
Rename it to `f2fs_is_compressed_folio`.
If a folio has f2fs_iomap_folio_state then it must not be
a compressed folio.
Signed-off-by: Nanzhe Zhao
---
fs/f2fs/compress.c | 11 ++-
fs/f2fs
The core function `f2fs_out_place_write` and `__get_segment_type_6`
in outplace write path haven't got their legacy page private functions
converted which can be harmful for large folios support.
Convert them to use our folio private funcions.
Signed-off-by: Nanzhe Zhao
--
types
(NULL_ADDR and unmapped dnodes).
They requiring different handle logic to set iomap.length,
So we add a new block state flag for f2fs_map_blocks
Signed-off-by: Nanzhe Zhao
---
fs/f2fs/data.c | 286 +++
fs/f2fs/f2fs.h | 120 +--
--bs=4K --fsync=1 --size=1G --ioengine=psync ???
```
Task Hangs in `f2fs_issue_flush`->'submit_bio_wait'
Full traces will be posted in a follow-up.
Nanzhe Zhao (9):
f2fs: Introduce f2fs_iomap_folio_state
f2fs: Integrate f2fs_iomap_folio_state into f2fs page private helpers
f2fs: Us
Dear Mr.Matthew and other fs developers:
I'm very sorry.My gmail maybe be blocked for reasons I don't know.I have to
change
my email domain.
> So, my proposal is that filesystems tell the page cache that their minimu=
m
> folio size is the compression block size. That seems to be around 64k,
> so
Dear Matthew and other filesystem developers,
I've been experimenting with implementing large folio support for
compressed files in F2FS locally, and I'd like to describe the
situation from the F2FS perspective.
> First, I believe that all filesystems work by compressing fixed-size
> plaintext in
d alsp store the corresponding folio's subpage's index in
fio?Or did I miss something in your newest patch?
Nanzhe Zhao 于2025年7月12日周六 21:02写道：
>
> Oh,I'm sorry,I forgot to put my github link in last email.But I haven't
> prepared an English document for descri
Dear Mr Matthew
Hi! It's been a long time since we last discuss about f2fs supporting
large folios. I hope you're doing well!
Over the past three months, I've been working on large folios support
in my own fork of the f2fs tree. I've made some significant progress
and have a working implementation
Dear Matthew,
Hope you are doing well.
I've recently made some progress in enabling iomap support for
buffered read and buffered write on regular files in f2fs. However,
I'm encountering significant challenges when it comes to supporting
iomap for page writeback.
Currently, the f2fs_write_cache_p
Dear f2fs Development Community,
This thread is initiated to discuss the challenge of integrating
iomap_folio_state (hereafter referred to as ifs) into f2fs pointed out
by Mr. Matthew in this email:
https://lore.kernel.org/linux-f2fs-devel/camlch1eosva1as4vdbcpsh75apfmknofhihorxvommz-+mu...@mail.g
though they are not yet fully formed. I am going to opening a
new thread on the f2fs mailing list in the near future to discuss this
matter further. I would greatly appreciate it if you could follow the
discussion there.
Nanzhe Zhao 于2025年4月5日周六 11:10写道：
Nanzhe Zhao 于2025年4月5日周六 11:10写道：
>
> Tha
:28写道：
>
> On Sun, Mar 23, 2025 at 07:34:59PM +0800, Nanzhe Zhao wrote:
> > I've recently been studying your patch 'f2fs: Remove uses of
> > writepage'. I understand the rationale behind it, especially with the
> > page cache and file I/O increasingly adopting f
Dear f2fs developers,
My name is [Your Name], and I am an undergraduate student from Nanjing
University of Technology in China. I am a newcomer to kernel
development, and I am currently learning about f2fs and working on
enabling large folio support.
After studying the concept of folios, especial
ogize for the length of this reply. It also seems that this
discussion has drifted somewhat from the original subject of this
thread. If you think it would be better to start a new thread, please
let me know.
Best regards.
Matthew Wilcox 于2025年4月2日周三 11:10写道：
Matthew Wilcox 于2025年4月2日周三 11:10写道：
&
applying so many patches from the mailing list
would be quite cumbersome.
Best regards.
Matthew Wilcox 于2025年3月31日周一 11:43写道：
>
> On Sun, Mar 30, 2025 at 10:38:37AM +0800, Nanzhe Zhao wrote:
> > I have been considering potential solutions to address this. Two
> > approaches I&#x
Dear f2fs developers,
I am writing to discuss a potential issue regarding the dirty_folio
implementation in f2fs and its potential impact on write
amplification.
Currently, the f2fs implementation of dirty_folio within
address_space_operations relies on filemap_dirty_folio. As
filemap_dirty_folio
Dear Mr.Mattew:
Thanks for your reply!
>The fundamental problem is that f2fs has no per-block data structure. In
> ext4, that's struct buffer_head. For XFS, it's struct iomap_folio_state.
> For btrfs, it's struct btrfs_subpage and for bcachefs, it's struct
> bch_folio.
Yes,now I'm fully aware of
Dear Mr.Matthew
I hope this email finds you well.
I've recently been studying your patch 'f2fs: Remove uses of
writepage'. I understand the rationale behind it, especially with the
page cache and file I/O increasingly adopting folios in place of the
traditional page structure. This trend indeed
25 matches
Mail list logo
