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: <20200618141644.GB16866@infradead.org>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ