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

[OGAWA Hirofumi]

OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx> writes:

> Bryanna Marihugh <bryannamarihugh@xxxxxxxxxxxxxxxxx> 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.

And maybe it needs to check unmount time (check how many dirty was
missing to flush).

Thanks.
-- 
OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx>