fsck.f2fs: flush device buffer before zone transition on zoned storage

[PATCH] fsck.f2fs: flush device buffer before zone transition on zoned storage

Posted by Daeho Jeong 3 days, 6 hours ago

From: Daeho Jeong <daehojeong@google.com>

On zoned storage devices (F2FS_ZONED_HM), fsck.f2fs opens block devices
with buffered I/O (O_RDWR). When a curseg fills up its current zone and
moves to a new zone in find_next_free_block(), pending buffered writes
to the previous zone may still reside in the OS page cache / I/O queue.

As a result, issuing a write to the newly allocated zone can happen before
the device hardware finishes committing all blocks of the previous zone,
causing the hardware to see an additional open zone request that exceeds
the device's max open zone limit (e.g. open zones exceeded error).

Fix this by calling f2fs_fsync_device() right before allocating a new zone
when crossing zone boundaries (!(segno % segs_per_zone)). This flushes
all pending writes to physical media, ensuring the device hardware
auto-closes (FULL) the previous zone before opening the new zone.

Signed-off-by: Daeho Jeong <daehojeong@google.com>
---
 fsck/mount.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fsck/mount.c b/fsck/mount.c
index 6f640a0..3bd40fe 100644
--- a/fsck/mount.c
+++ b/fsck/mount.c
@@ -3073,6 +3073,9 @@ int find_next_free_block(struct f2fs_sb_info *sbi, u64 *to, int left,
 			if (!(segno % segs_per_zone)) {
 				u64 new_blkaddr = SM_I(sbi)->main_blkaddr;
 
+				if (c.zoned_model == F2FS_ZONED_HM)
+					f2fs_fsync_device();
+
 				ret = find_next_free_block(sbi, &new_blkaddr, 0,
 						want_type, true);
 				if (ret)
-- 
2.55.0.229.g6434b31f56-goog

Re: [f2fs-dev] [PATCH] fsck.f2fs: flush device buffer before zone transition on zoned storage

Posted by Bart Van Assche 2 days, 9 hours ago

On 7/21/26 9:47 AM, Daeho Jeong wrote:
> On zoned storage devices (F2FS_ZONED_HM), fsck.f2fs opens block devices
> with buffered I/O (O_RDWR). When a curseg fills up its current zone and
> moves to a new zone in find_next_free_block(), pending buffered writes
> to the previous zone may still reside in the OS page cache / I/O queue.
> 
> As a result, issuing a write to the newly allocated zone can happen before
> the device hardware finishes committing all blocks of the previous zone,
> causing the hardware to see an additional open zone request that exceeds
> the device's max open zone limit (e.g. open zones exceeded error).
> 
> Fix this by calling f2fs_fsync_device() right before allocating a new zone
> when crossing zone boundaries (!(segno % segs_per_zone)). This flushes
> all pending writes to physical media, ensuring the device hardware
> auto-closes (FULL) the previous zone before opening the new zone.
> 
> Signed-off-by: Daeho Jeong <daehojeong@google.com>
> ---
>   fsck/mount.c | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/fsck/mount.c b/fsck/mount.c
> index 6f640a0..3bd40fe 100644
> --- a/fsck/mount.c
> +++ b/fsck/mount.c
> @@ -3073,6 +3073,9 @@ int find_next_free_block(struct f2fs_sb_info *sbi, u64 *to, int left,
>   			if (!(segno % segs_per_zone)) {
>   				u64 new_blkaddr = SM_I(sbi)->main_blkaddr;
>   
> +				if (c.zoned_model == F2FS_ZONED_HM)
> +					f2fs_fsync_device();
> +
>   				ret = find_next_free_block(sbi, &new_blkaddr, 0,
>   						want_type, true);
>   				if (ret)

Will this change make a difference on Android because the Android
f2fs-tools already use O_DSYNC when opening a zoned block device?
 From lib/libf2fs.c:

                 if (dev->zoned_model == F2FS_ZONED_HM)
                         flags |= O_DSYNC;

See also commit 10dad5ed7ce1 ("f2fs-tools: support zoned ufs devices").

Thanks,

Bart.

Re: [f2fs-dev] [PATCH] fsck.f2fs: flush device buffer before zone transition on zoned storage

Posted by Daeho Jeong 2 days, 8 hours ago

On Wed, Jul 22, 2026 at 6:51 AM Bart Van Assche <bvanassche@acm.org> wrote:
>
> On 7/21/26 9:47 AM, Daeho Jeong wrote:
> > On zoned storage devices (F2FS_ZONED_HM), fsck.f2fs opens block devices
> > with buffered I/O (O_RDWR). When a curseg fills up its current zone and
> > moves to a new zone in find_next_free_block(), pending buffered writes
> > to the previous zone may still reside in the OS page cache / I/O queue.
> >
> > As a result, issuing a write to the newly allocated zone can happen before
> > the device hardware finishes committing all blocks of the previous zone,
> > causing the hardware to see an additional open zone request that exceeds
> > the device's max open zone limit (e.g. open zones exceeded error).
> >
> > Fix this by calling f2fs_fsync_device() right before allocating a new zone
> > when crossing zone boundaries (!(segno % segs_per_zone)). This flushes
> > all pending writes to physical media, ensuring the device hardware
> > auto-closes (FULL) the previous zone before opening the new zone.
> >
> > Signed-off-by: Daeho Jeong <daehojeong@google.com>
> > ---
> >   fsck/mount.c | 3 +++
> >   1 file changed, 3 insertions(+)
> >
> > diff --git a/fsck/mount.c b/fsck/mount.c
> > index 6f640a0..3bd40fe 100644
> > --- a/fsck/mount.c
> > +++ b/fsck/mount.c
> > @@ -3073,6 +3073,9 @@ int find_next_free_block(struct f2fs_sb_info *sbi, u64 *to, int left,
> >                       if (!(segno % segs_per_zone)) {
> >                               u64 new_blkaddr = SM_I(sbi)->main_blkaddr;
> >
> > +                             if (c.zoned_model == F2FS_ZONED_HM)
> > +                                     f2fs_fsync_device();
> > +
> >                               ret = find_next_free_block(sbi, &new_blkaddr, 0,
> >                                               want_type, true);
> >                               if (ret)
>
> Will this change make a difference on Android because the Android
> f2fs-tools already use O_DSYNC when opening a zoned block device?
>  From lib/libf2fs.c:
>
>                  if (dev->zoned_model == F2FS_ZONED_HM)
>                          flags |= O_DSYNC;
>
> See also commit 10dad5ed7ce1 ("f2fs-tools: support zoned ufs devices").

Oops, we already have this patch upstream.
Plz, ignore this patch.

Bart, thanks for letting me know this.

>
> Thanks,
>
> Bart.
>