On Sun, 21 Nov 2021, OGAWA Hirofumi wrote:
> "NeilBrown" <neilb@xxxxxxx> writes:
>
> > congestion_wait() in this context is just a sleep - block devices do not
> > 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().
>
> Purpose of flush option should be for making umount faster, not data
> integrity. (but current flush implement is strange at several places, IMO)
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".
>
> 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".
Thanks,
NeilBrown
>
> Thanks.
>
> > Signed-off-by: NeilBrown <neilb@xxxxxxx>
> > ---
> > fs/fat/file.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/fat/file.c b/fs/fat/file.c
> > index 13855ba49cd9..c50a52f40e37 100644
> > --- a/fs/fat/file.c
> > +++ b/fs/fat/file.c
> > @@ -175,9 +175,9 @@ long fat_generic_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
> > static int fat_file_release(struct inode *inode, struct file *filp)
> > {
> > if ((filp->f_mode & FMODE_WRITE) &&
> > - MSDOS_SB(inode->i_sb)->options.flush) {
> > + MSDOS_SB(inode->i_sb)->options.flush) {
> > fat_flush_inodes(inode->i_sb, inode, NULL);
> > - congestion_wait(BLK_RW_ASYNC, HZ/10);
> > + blkdev_issue_flush(inode->i_sb->s_bdev);
> > }
> > return 0;
> > }
>
> --
> OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx>
>
>
