linux-kernel - Re: [PATCH 0/3] zone-append support in aio and io-uring

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]

Date:   Thu, 18 Jun 2020 07:16:44 -0700
From:   Christoph Hellwig <hch@...radead.org>
To:     Matias Bjørling <mb@...htnvm.io>
Cc:     Kanchan Joshi <joshi.k@...sung.com>, axboe@...nel.dk,
        viro@...iv.linux.org.uk, bcrl@...ck.org,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-aio@...ck.org, io-uring@...r.kernel.org,
        linux-block@...r.kernel.org, selvakuma.s1@...sung.com,
        nj.shetty@...sung.com, javier.gonz@...sung.com,
        Damien Le Moal <Damien.LeMoal@....com>,
        Keith Busch <keith.busch@....com>,
        Christoph Hellwig <hch@....de>
Subject: Re: [PATCH 0/3] zone-append support in aio and io-uring

On Thu, Jun 18, 2020 at 10:04:32AM +0200, Matias Bjørling wrote:
> Please provide a pointers to applications that are updated and ready to take
> advantage of zone append.

That is a pretty high bar for kernel APIs that we don't otherwise
apply unless seriously in doubt.

> I do not believe it's beneficial at this point to change the libaio API,
> applications that would want to use this API, should anyway switch to use
> io_uring.

I think that really depends on the amount of churn required.  We
absolutely can expose things like small additional flags or simple
new operations, as rewriting application to different APIs is not
exactly trivial.  On the other hand we really shouldn't do huge
additions to the machinery.

> Please also note that applications and libraries that want to take advantage
> of zone append, can already use the zonefs file-system, as it will use the
> zone append command when applicable.

Not really.  While we already use Zone Append in Zonefs for some cases,
we can't fully take advantage of the scalability of Zone Append.  For
that we'd need a way to return the file position where an O_APPEND
write actually landed, as suggested in my earlier mail.  Which I think
is a very useful addition, and Damien and I had looked into adding
it both for zonefs and normal file systems, but didn't get around to
doing the work yet.