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: <6489b8cb-7d54-1e29-f192-a3449ed87fa1@gmail.com>
Date: Fri, 8 Sep 2023 01:29:55 +0100
From: Pavel Begunkov <asml.silence@...il.com>
To: Dave Chinner <david@...morbit.com>, Hao Xu <hao.xu@...ux.dev>
Cc: Matthew Wilcox <willy@...radead.org>, io-uring@...r.kernel.org,
 Jens Axboe <axboe@...nel.dk>, Dominique Martinet <asmadeus@...ewreck.org>,
 Christian Brauner <brauner@...nel.org>,
 Alexander Viro <viro@...iv.linux.org.uk>, Stefan Roesch <shr@...com>,
 Clay Harris <bugs@...ycon.org>, "Darrick J . Wong" <djwong@...nel.org>,
 linux-fsdevel@...r.kernel.org, linux-xfs@...r.kernel.org,
 linux-ext4@...r.kernel.org, linux-cachefs@...hat.com,
 ecryptfs@...r.kernel.org, linux-nfs@...r.kernel.org,
 linux-unionfs@...r.kernel.org, bpf@...r.kernel.org, netdev@...r.kernel.org,
 linux-s390@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-block@...r.kernel.org, linux-btrfs@...r.kernel.org,
 codalist@...a.cs.cmu.edu, linux-f2fs-devel@...ts.sourceforge.net,
 cluster-devel@...hat.com, linux-mm@...ck.org, linux-nilfs@...r.kernel.org,
 devel@...ts.orangefs.org, linux-cifs@...r.kernel.org,
 samba-technical@...ts.samba.org, linux-mtd@...ts.infradead.org,
 Wanpeng Li <wanpengli@...cent.com>
Subject: Re: [PATCH 07/11] vfs: add nowait parameter for file_accessed()

On 9/3/23 23:30, Dave Chinner wrote:
> On Wed, Aug 30, 2023 at 02:11:31PM +0800, Hao Xu wrote:
>> On 8/29/23 19:53, Matthew Wilcox wrote:
>>> On Tue, Aug 29, 2023 at 03:46:13PM +0800, Hao Xu wrote:
>>>> On 8/28/23 05:32, Matthew Wilcox wrote:
>>>>> On Sun, Aug 27, 2023 at 09:28:31PM +0800, Hao Xu wrote:
>>>>>> From: Hao Xu <howeyxu@...cent.com>
>>>>>>
>>>>>> Add a boolean parameter for file_accessed() to support nowait semantics.
>>>>>> Currently it is true only with io_uring as its initial caller.
>>>>>
>>>>> So why do we need to do this as part of this series?  Apparently it
>>>>> hasn't caused any problems for filemap_read().
>>>>>
>>>>
>>>> We need this parameter to indicate if nowait semantics should be enforced in
>>>> touch_atime(), There are locks and maybe IOs in it.
>>>
>>> That's not my point.  We currently call file_accessed() and
>>> touch_atime() for nowait reads and nowait writes.  You haven't done
>>> anything to fix those.
>>>
>>> I suspect you can trim this patchset down significantly by avoiding
>>> fixing the file_accessed() problem.  And then come back with a later
>>> patchset that fixes it for all nowait i/o.  Or do a separate prep series
>>
>> I'm ok to do that.
>>
>>> first that fixes it for the existing nowait users, and then a second
>>> series to do all the directory stuff.
>>>
>>> I'd do the first thing.  Just ignore the problem.  Directory atime
>>> updates cause I/O so rarely that you can afford to ignore it.  Almost
>>> everyone uses relatime or nodiratime.
>>
>> Hi Matthew,
>> The previous discussion shows this does cause issues in real
>> producations: https://lore.kernel.org/io-uring/2785f009-2ebb-028d-8250-d5f3a30510f0@gmail.com/#:~:text=fwiw%2C%20we%27ve%20just%20recently%20had%20similar%20problems%20with%20io_uring%20read/write
>>
> 
> Then separate it out into it's own patch set so we can have a
> discussion on the merits of requiring using noatime, relatime or
> lazytime for really latency sensitive IO applications. Changing code
> is not always the right solution...

Separation sounds reasonable, but it can hardly be said that only
latency sensitive apps would care about >1s nowait/async submission
delays. Presumably, btrfs can improve on that, but it still looks
like it's perfectly legit for filesystems do heavy stuff in
timestamping like waiting for IO. Right?

-- 
Pavel Begunkov

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ