lkml.org 
[lkml]   [2021]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] FAT: use blkdev_issue_flush() instead of congestion_wait()
Date
"NeilBrown" <neilb@suse.de> writes:

> On Mon, 22 Nov 2021, OGAWA Hirofumi wrote:
>> "NeilBrown" <neilb@suse.de> writes:
>>
>> Right. This was to make the removable device usage better (but sync
>> option is too slow).
>>
>> e.g.
>> # cp -a /foo/source /mnt/fatfs
>>
>> # umount <don't too slow>
>> or
>> <do other thing, and forget umount>
>
> or use GUI to drag a file to the removable device, wait for the copy to
> appear to finish, then pull the device.
>
> sync is too slow as it flush each change to storage as it happens. Each
> block, each FA-Table update etc.
>
> "-o flush" does the flush as file-close rather than on each write.
> But it still needs to provide the same safety. i.e. write and flush and
> wait.

If you want to provide the data integrity, e.g., you have to check and
sync parent recursively. And more.

>> It makes much slower above "cp -a" part. So I think it is overkill.
>
> There doesn't seem to be any point to "-o flush" if it doesn't promise
> anything. Without the blkdeV_issue_flush() we have no guarantee that
> the data is safe after the file is closed - do we?
> Certainly it will be slower than without "-o flush", but that is the
> price you pay for safety.

What I originally think to provide here (before this patch) is,
removable media capable flusher (early flush) + some sort of auto
unmount (syncfs when fs becomes idle.). IOW, nearly maximum throughput
and better safety than default fluser. But never guarantee anything the
data integrity, otherwise this option becomes too complex and heavyweight.

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

\
 
 \ /
  Last update: 2021-12-11 09:17    [W:0.059 / U:0.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site