linux-ext4 - Re: [PATCH 1/2] fs: add FMODE_DIO_PARALLEL

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: <e4855cfa-3683-f12c-e865-6e5c4d0e5602@ddn.com>
Date:   Tue, 18 Apr 2023 12:55:40 +0000
From:   Bernd Schubert <bschubert@....com>
To:     Miklos Szeredi <miklos@...redi.hu>, Jens Axboe <axboe@...nel.dk>
CC:     "Darrick J. Wong" <djwong@...nel.org>,
        Christoph Hellwig <hch@...radead.org>,
        "io-uring@...r.kernel.org" <io-uring@...r.kernel.org>,
        "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "linux-xfs@...r.kernel.org" <linux-xfs@...r.kernel.org>,
        Dharmendra Singh <dsingh@....com>
Subject: Re: [PATCH 1/2] fs: add FMODE_DIO_PARALLEL_WRITE flag

On 4/18/23 14:42, Miklos Szeredi wrote:
> On Sat, 15 Apr 2023 at 15:15, Jens Axboe <axboe@...nel.dk> wrote:
> 
>> Yep, that is pretty much it. If all writes to that inode are serialized
>> by a lock on the fs side, then we'll get a lot of contention on that
>> mutex. And since, originally, nothing supported async writes, everything
>> would get punted to the io-wq workers. io_uring added per-inode hashing
>> for this, so that any punt to io-wq of a write would get serialized.
>>
>> IOW, it's an efficiency thing, not a correctness thing.
> 
> We could still get a performance regression if the majority of writes
> still trigger the exclusive locking.  The questions are:
> 
>   - how often does that happen in real life?

Application depending? My personal opinion is that 
applications/developers knowing about uring would also know that they 
should set the right file size first. Like MPIIO is extending files 
persistently and it is hard to fix with all these different MPI stacks 
(I can try to notify mpich and mvapich developers). So best would be to 
document it somewhere in the uring man page that parallel extending 
files might have negative side effects?


>   - how bad the performance regression would be?

I can give it a try with fio and fallocate=none over fuse during the 
next days.

> 
> Without first attempting to answer those questions, I'd be reluctant
> to add  FMODE_DIO_PARALLEL_WRITE to fuse.
> 


Bernd