[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9b88f077-616a-64f4-287a-77f5c3b8b07a@yandex-team.ru>
Date: Thu, 2 Apr 2020 12:49:15 +0300
From: Konstantin Khlebnikov <khlebnikov@...dex-team.ru>
To: "Martin K. Petersen" <martin.petersen@...cle.com>
Cc: Chaitanya Kulkarni <chaitanya.kulkarni@....com>, hch@....de,
darrick.wong@...cle.com, axboe@...nel.dk, tytso@....edu,
adilger.kernel@...ger.ca, ming.lei@...hat.com, jthumshirn@...e.de,
minwoo.im.dev@...il.com, damien.lemoal@....com,
andrea.parri@...rulasolutions.com, hare@...e.com, tj@...nel.org,
hannes@...xchg.org, ajay.joshi@....com, bvanassche@....org,
arnd@...db.de, houtao1@...wei.com, asml.silence@...il.com,
linux-block@...r.kernel.org, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 0/4] block: Add support for REQ_OP_ASSIGN_RANGE
On 02/04/2020 05.29, Martin K. Petersen wrote:
>
> Konstantin,
>
>>> The corresponding exported primitive is called
>>> blkdev_issue_assign_range().
>>
>> What exact semantics of that?
>
> REQ_OP_ALLOCATE will be used to compel a device to allocate a block
> range. What a given block contains after successful allocation is
> undefined (depends on the device implementation).
Ok. Then REQ_OP_ALLOCATE should be accounted as discard rather than write.
That's decided by helper op_is_discard() which is used only by statistics.
It seems REQ_OP_SECURE_ERASE also should be accounted in this way.
>
> For block allocation with deterministic zeroing, one must keep using
> REQ_OP_WRITE_ZEROES with the NOUNMAP flag set.
>
Powered by blists - more mailing lists