From: Christoph Hellwig <hch@infradead.org>
To: Sarthak Kukreti <sarthakkukreti@chromium.org>
Cc: Jens Axboe <axboe@kernel.dk>,
Gwendal Grignou <gwendal@google.com>,
Theodore Ts'o <tytso@mit.edu>,
"Michael S . Tsirkin" <mst@redhat.com>,
Bart Van Assche <bvanassche@google.com>,
Mike Snitzer <snitzer@kernel.org>,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
linux-block@vger.kernel.org, dm-devel@redhat.com,
Andreas Dilger <adilger.kernel@dilger.ca>,
Daniil Lunev <dlunev@google.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
linux-ext4@vger.kernel.org, Evan Green <evgreen@google.com>,
Alasdair Kergon <agk@redhat.com>
Subject: Re: [PATCH RFC 4/8] fs: Introduce FALLOC_FL_PROVISION
Date: Tue, 20 Sep 2022 00:49:13 -0700 [thread overview]
Message-ID: <YylweQAZkIdb5ixo@infradead.org> (raw)
In-Reply-To: <20220915164826.1396245-5-sarthakkukreti@google.com>
On Thu, Sep 15, 2022 at 09:48:22AM -0700, Sarthak Kukreti wrote:
> From: Sarthak Kukreti <sarthakkukreti@chromium.org>
>
> FALLOC_FL_PROVISION is a new fallocate() allocation mode that
> sends a hint to (supported) thinly provisioned block devices to
> allocate space for the given range of sectors via REQ_OP_PROVISION.
So, how does that "provisioning" actually work in todays world where
storage is usually doing out of place writes in one or more layers,
including the flash storage everyone is using. Does it give you one
write? And unlimited number? Some undecided number inbetween? How
is it affected by write zeroes to that range or a discard?
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2022-09-20 7:49 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20220915164826.1396245-1-sarthakkukreti@google.com>
2022-09-16 6:09 ` [PATCH RFC 0/8] Introduce provisioning primitives for thinly provisioned storage Stefan Hajnoczi
[not found] ` <CAG9=OMPHZqdDhX=M+ovdg5fa3x4-Q_1r5SWPa8pMTQw0mr5fPg@mail.gmail.com>
2022-09-16 20:01 ` Bart Van Assche
2022-09-20 7:46 ` Christoph Hellwig
[not found] ` <CAAKderPF5Z5QLxyEb80Y+90+eR0sfRmL-WfgXLp=eL=HxWSZ9g@mail.gmail.com>
2022-09-20 11:30 ` Christoph Hellwig
[not found] ` <CAAKderNcHpbBqWqqd5-WuKLRCQQUt7a_4D4ti4gy15+fKGK0vQ@mail.gmail.com>
2022-09-21 15:08 ` Mike Snitzer
2022-09-23 8:51 ` Christoph Hellwig
2022-09-23 14:08 ` Mike Snitzer
[not found] ` <20220915164826.1396245-5-sarthakkukreti@google.com>
2022-09-16 11:56 ` [PATCH RFC 4/8] fs: Introduce FALLOC_FL_PROVISION Brian Foster
[not found] ` <CAG9=OMNL1Z3DiO-usdH0k90NDsDkDQ7A7CHc4Nu6MCXKNKjWdw@mail.gmail.com>
2022-09-21 15:39 ` Brian Foster
[not found] ` <CAG9=OMPEoShYMx6A+p97-tw4MuLpgOEpy7aFs5CH6wTedptALQ@mail.gmail.com>
2022-09-22 18:29 ` Brian Foster
2022-09-20 7:49 ` Christoph Hellwig [this message]
[not found] ` <CAG9=OMNoG01UUStNs_Zhsv6mXZw0M0q2v54ZriJvHZ4aspvjEQ@mail.gmail.com>
2022-09-21 15:21 ` Mike Snitzer
2022-09-23 8:45 ` Christoph Hellwig
[not found] ` <YyU5CyQfS+64xmnm@magnolia>
[not found] ` <CAG9=OMNPnsjaUw2EUG0XFjV94-V1eD63V+1anoGM=EWKyzXEfg@mail.gmail.com>
2022-09-19 16:36 ` [dm-devel] [PATCH RFC 0/8] Introduce provisioning primitives for thinly provisioned storage Stefan Hajnoczi
[not found] ` <20220915164826.1396245-3-sarthakkukreti@google.com>
2022-09-23 14:23 ` [PATCH RFC 2/8] dm: Add support for block provisioning Mike Snitzer
[not found] ` <20220915164826.1396245-2-sarthakkukreti@google.com>
2022-09-23 15:15 ` [PATCH RFC 1/8] block: Introduce provisioning primitives Mike Snitzer
[not found] ` <20220915164826.1396245-4-sarthakkukreti@google.com>
2022-09-16 5:48 ` [PATCH RFC 3/8] virtio_blk: Add support for provision requests Stefan Hajnoczi
2022-09-27 21:37 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YylweQAZkIdb5ixo@infradead.org \
--to=hch@infradead.org \
--cc=adilger.kernel@dilger.ca \
--cc=agk@redhat.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@google.com \
--cc=dlunev@google.com \
--cc=dm-devel@redhat.com \
--cc=evgreen@google.com \
--cc=gwendal@google.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=sarthakkukreti@chromium.org \
--cc=snitzer@kernel.org \
--cc=stefanha@redhat.com \
--cc=tytso@mit.edu \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).