Re: [PATCH RFC] fat: use write_inode_now() on flush to avoid racing the flusher

[OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>]

Bryanna Marihugh <bryannamarihugh@manhattantech.edu> writes:

> On 10/29/26 2:56 PM, OGAWA Hirofumi wrote:
>> Looks like this waits the I/O, and sounds like optimization only for
>> specific drives. Well, so no slowdown for other drives by this patch?
>
> Thanks for the rapid reply and feedback.
>
> writeback_inode is called only when flush is set. My understanding is
> that mode is for storage that could disconnect. I set write_inode_now
> to wait as that seemed to be right for flush. Given it does change
> behavior I should have explained that better. I can change it to 0 if
> you want the old behavior. Because I_SYNC is still set no matter if
> it waits or not, it should keep the kernel flusher from writing the
> same file.
>
> I focused on the reduced write request size causing the stall, and
> tested for slowdowns mostly doing a cp and looking at the times, for
> big and small files. Everything in MB/s
>
> PNY 32G stick (usb-storage), copying a 3 GiB file 3x
>
>   before: 16.3, 13.2, 11.6
>   after:  18.0, 18.0, 17.6
>
> Samsung 64G stick (usb-storage), copying a 3 GiB file 3x
>
>   before: 33.4, 33.5, 33.5
>   after:  33.5, 33.5, 33.5
>
> PNY 250G stick (uas), copying a 4 GiB file 3x
>
>   before: 365, 200, 322
>   after:  365, 255, 251
>
> Samsung 870 EVO in a USB-SATA adapter (uas), copying a 4 GiB file 3x
>
>   before: 379, 346, 346
>   after:  376, 378, 379
>
> The PNY 250G numbers vary on both kernels because the stick slows
> itself down partway through.
>
> For small files I saw maybe improvements on the cheap stick, with no
> harm on the nicer Samsung stick.
>
> PNY 32G stick (usb-storage), copying 1000 x 1 MiB files 2x
>
>   before: 5.37, 5.55
>   after:  5.64, 5.62
>
> Samsung 64G stick (usb-storage), copying 1000 x 1 MiB files 2x
>
>   before: 7.33, 7.37
>   after:  7.35, 7.36
>
> PNY 250G stick (uas), copying 1000 x 1 MiB files 2x
>
>   before: 9.61, 9.61
>   after:  9.28, 9.26
>
> 870 EVO in USB-SATA adapter (uas), copying 1000 x 1 MiB files 2x
>
>   before: 9.61, 9.61
>   after:  9.59, 9.51
>
> There is some regression with small files on the uas drives from the
> wait.

Is this wait=1? The flush should just be early flush, no guarantee to
flush completely. So I think it should be wait=0.

And the flush is assuming basically for removable media though, we can't
choose. I think we need to check the result of such HDD/SSD.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>