Subject: Re: [Drbd-dev] [PATCH 05/30] drbd: Introduce new disk config option
 rs-discard-granularity
To: Philipp Reisner <philipp.reisner@linbit.com>
References: <1461586077-11581-1-git-send-email-philipp.reisner@linbit.com>
 <1461586077-11581-6-git-send-email-philipp.reisner@linbit.com>
 <571E393E.1010003@sandisk.com> <2101862.7IMGIqiMZK@phil-dell-xps.local>
CC: Jens Axboe <axboe@fb.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "drbd-dev@lists.linbit.com" <drbd-dev@lists.linbit.com>
From: Bart Van Assche <bart.vanassche@sandisk.com>
Message-ID: <571E667E.4080200@sandisk.com>
Date: Mon, 25 Apr 2016 11:48:30 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <2101862.7IMGIqiMZK@phil-dell-xps.local>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Apr 2016 18:48:30.9342
 (UTC)
X-MS-Exchange-CrossTenant-Id: fcd9ea9c-ae8c-460c-ab3c-3db42d7ac64d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=fcd9ea9c-ae8c-460c-ab3c-3db42d7ac64d;Ip=[63.163.107.21];Helo=[milsmgep15.sandisk.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0201MB1871
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1390
Lines: 30

On 04/25/2016 09:42 AM, Philipp Reisner wrote:
> Am Montag, 25. April 2016, 08:35:26 schrieb Bart Van Assche:
>> On 04/25/2016 05:10 AM, Philipp Reisner wrote:
>>> As long as the value is 0 the feature is disabled. With setting
>>> it to a positive value, DRBD limits and aligns its resync requests
>>> to the rs-discard-granularity setting. If the sync source detects
>>> all zeros in such a block, the resync target discards the range
>>> on disk.
>>
>> Can you explain why rs-discard-granularity is configurable instead of
>> e.g. setting it to the least common multiple of the discard
>> granularities of the underlying block devices at both sides?
>
> we had this idea as well. It seems that real world devices like larger
> discards better than smaller discards. The other motivation was that
> a device mapper logical volume might change it on the fly...
> So we think it is best to delegate the decision on the discard chunk
> size to user space.

Hello Phil,

Are you aware that for aligned discard requests the discard granularity 
does not affect the size of discard requests at all?

Regarding LVM volumes: if the discard granularity for such volumes can 
change on the fly, shouldn't I/O be quiesced by the LVM kernel driver 
before it changes the discard granularity? I think that increasing 
discard granularity while I/O is in progress should be considered as a bug.

Bart.