Re: [f2fs-dev] [PATCH v3] f2fs: issue multi-device flushes in parallel

Chao Yu via Linux-f2fs-devel <[email protected]> Thu, 6 Aug 2026 11:46:16 +0800
Newsgroups net.sourceforge.lists.linux-f2fs-devel,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On 8/6/26 11:39, Yonggil Song wrote:
> On a multi-device setup, submit_flush_wait() walked the dirty devices
> in order and aborted the whole loop on the first device whose flush
> failed, leaving the remaining dirty devices un-flushed. Each device
> still needs its own data made durable, so a failure on one device must
> not skip the others. It also waited for one device's flush to complete
> before issuing the next, even though the devices have independent
> flush queues and could be flushed concurrently.
> 
> Flush every dirty device best-effort and in parallel instead: build
> one PREFLUSH bio per dirty device, submit them all, then wait for
> every completion, returning the first error seen (0 if all succeed).
> This bounds the flush window by the slowest device rather than the sum
> of all of them. No caller depends on the previous early-abort
> behaviour -- fsync only checks whether the return value is zero
> (fs/f2fs/file.c). The checkpoint path (f2fs_flush_device_cache) is
> unaffected; this only touches the fsync flush path.
> 
> The per-device bio/completion array is small and bounded (at most
> MAX_DEVICES entries), so allocate it with __GFP_NOFAIL rather than
> keeping a separate serial fallback path for allocation failure.
> 
> Signed-off-by: Yonggil Song <[email protected]>
Reviewed-by: Chao Yu <[email protected]>

Thanks,


_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel