linux-kernel - Re: [PATCH 3/3] block: by default, limit maximum discard size to 64MB

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:	Wed, 15 Jul 2015 09:30:37 -0600
From:	Jens Axboe <axboe@...com>
To:	Austin S Hemmelgarn <ahferroin7@...il.com>,
	Mike Snitzer <snitzer@...hat.com>
CC:	<linux-kernel@...r.kernel.org>, <hch@....de>
Subject: Re: [PATCH 3/3] block: by default, limit maximum discard size to
 64MB

On 07/15/2015 05:46 AM, Austin S Hemmelgarn wrote:
> On 2015-07-14 17:48, Jens Axboe wrote:
>> On 07/14/2015 02:45 PM, Jens Axboe wrote:
>>> On 07/14/2015 02:44 PM, Mike Snitzer wrote:
>>>> On Tue, Jul 14 2015 at  2:48pm -0400,
>>>> Jens Axboe <axboe@...com> wrote:
>>>>
>>>>> Lots of devices exhibit very high latencies for big discards, hurting
>>>>> reads and writes. By default, limit the max discard we will build to
>>>>> 64MB. This value has shown good results across a number of devices.
>>>>>
>>>>> This will potentially hurt discard throughput, from a provisioning
>>>>> point of view (when the user does mkfs.xfs, for instance, and mkfs
>>>>> issues a full device discard). If that becomes an issue, we could
>>>>> have different behavior for provisioning vs runtime discards.
>>>>>
>>>>> Signed-off-by: Jens Axboe <axboe@...com>
>>>>
>>>> Christoph suggested you impose this default for the specific
>>>> drivers/devices that benefit.  I'm not following why imposing a 64MB
>>>> default is the right thing to do for all devices.
>>>
>>> I'd argue that's most of them... But the testing we did was on NVMe. I
>>> can limit it to NVMe, no big deal.
>>
>> Oh, and LSI flash too, so not just NVMe.
>>
> While I don't have time to test it, I have a feeling that such a limit
> would help with many of the consumer SSD's out there.  Secondarily, once
> this gets in and discard is fixed for BTRFS, I'll have some performance
> testing to do WRT dm-thinp.

Right, that was the point of it. After more consideration, a default 
"sane" limit should be applied to any non-stacked device.

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/