Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
From:   "NeilBrown" <neilb@suse.de>
To:     "OGAWA Hirofumi" <hirofumi@mail.parknet.co.jp>
Cc:     linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
        Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH] FAT: use blkdev_issue_flush() instead of congestion_wait()
In-reply-to: <874k84hi5q.fsf@mail.parknet.co.jp>
References: <163712349419.13692.2859038330142282757@noble.neil.brown.name>,
 <87ee79yiik.fsf@mail.parknet.co.jp>,
 <163754226639.13692.10449616189734943162@noble.neil.brown.name>,
 <874k84hi5q.fsf@mail.parknet.co.jp>
Date:   Fri, 10 Dec 2021 15:21:56 +1100
Message-id: <163911011670.9928.6438117555175130033@noble.neil.brown.name>
Precedence: bulk

On Mon, 22 Nov 2021, OGAWA Hirofumi wrote:
> "NeilBrown" <neilb@suse.de> writes:
>=20
> > On Sun, 21 Nov 2021, OGAWA Hirofumi wrote:
> >> "NeilBrown" <neilb@suse.de> writes:
> >>=20
> >> > congestion_wait() in this context is just a sleep - block devices do n=
ot
> >> > in general support congestion signalling any more.
> >> >
> >> > The goal here is to wait for any recently written data to get to
> >> > storage.  This can be achieved using blkdev_issue_flush().
> >>=20
> >> Purpose of flush option should be for making umount faster, not data
> >> integrity. (but current flush implement is strange at several places, IM=
O)
> >
> > I don't think that is true.  I believe the purpose of the flush option
> > is to write out data as soon as a file is closed, so that if the media
> > is removed without first unmounting, the data is more likely to be safe.
> > That is why the commit which introduce it:
> >  Commit ae78bf9c4f5f ("[PATCH] add -o flush for fat")
> > particularly mentions "removable media".
>=20
> Right. This was to make the removable device usage better (but sync
> option is too slow).
>=20
> e.g.
>     # cp -a /foo/source /mnt/fatfs
>=20
>     # 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.

>=20
> >> So, I don't think the issue_flush is not proper for it (flush is very
> >> slow on some usb thumb), and rather I think it is better off to just
> >> remove the congestion_wait().
> >
> > We already call blkdev_issue_flush() on fsync.  With my patch, a simple
> > close() effective becomes an fsync() and a close().  I think that is
> > completely consistent with the purpose of "-o flush".
>=20
> 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.

However, if you are adamant then let's just put in a timeout.
Patch to follow.

Thanks,
NeilBrown