linux-kernel - Re: [PATCH] FAT: use blkdev_issue_flush() instead of congestion

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87lf0rmu8t.fsf@mail.parknet.co.jp>
Date:   Sat, 11 Dec 2021 17:16:34 +0900
From:   OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To:     "NeilBrown" <neilb@...e.de>
Cc:     linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
        Christoph Hellwig <hch@...radead.org>
Subject: Re: [PATCH] FAT: use blkdev_issue_flush() instead of congestion_wait()

"NeilBrown" <neilb@...e.de> writes:

> On Mon, 22 Nov 2021, OGAWA Hirofumi wrote:
>> "NeilBrown" <neilb@...e.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@...l.parknet.co.jp>