[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZJmBmt3WmUpWR3+2@casper.infradead.org>
Date: Mon, 26 Jun 2023 13:16:26 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Yangtao Li <frank.li@...o.com>
Cc: Jens Axboe <axboe@...nel.dk>, Jaegeuk Kim <jaegeuk@...nel.org>,
Lu Hongfei <luhongfei@...o.com>,
linux-f2fs-devel@...ts.sourceforge.net,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: f2fs async buffered write patch
On Mon, Jun 26, 2023 at 03:31:57PM +0800, Yangtao Li wrote:
> +cc willy@...radead.org
>
>
> On 2023/6/20 4:43, Jens Axboe wrote:
>
> > Hi,
> >
> > I came across this patch in a news posting:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git/commit/?h=dev&id=d618126911829523e35a61f4a5a4ad159b1b2c8d
> >
> > which has me a bit worried. As far as I can tell, all that patch does is
> > set FMODE_BUF_WASYNC, and then just hope that the lower layers handle
> > the rest?
> >
> > What happens if iocb->ki_flags & IOCB_NOWAIT is true, and now we do:
> >
> > generic_perform_write(iocb, from)
> > ...
> > ->write_begin() <- does this block?
>
> Most file systems have not been changed to the iomap method,
That's what needs to be fixed.
> and the generic_perform_write method is still used. So it seems
>
> reasonable to make IOCB_NOWAIT be handled correctly by the
>
> generic_perform_write function. This means that we need to modify
No. Use the modern infrastructure.
> several places mentioned by Jens in the generic_perform_write function,
>
> and need to pass AOP_FLAG_xxx or iocb into write_begin.
Definitely not.
>
> I noticed that Matthew Wilcox removed the flags parameter in write_begin
>
> in a previous commit, maybe we can add it back?
No.
Powered by blists - more mailing lists