From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D00D8221F11 for ; Thu, 12 Feb 2026 15:01:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770908508; cv=none; b=mNumwcn/+u3azhwvg9OAsf6k4OFpdGD+M0FBYiTuhcdh929sYmWRkwXbtF2uk7xbQql8K67bGg77FXJXwFPsBH6R9Mtk1HvuDOHK+h4O57VXNerMUDWUUh2Q+k6NOIGqK9O2xPo4nySWt9jGIa+e52oQK9QbVbG26xTNVBULr/U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770908508; c=relaxed/simple; bh=SU9IhclmYAClkIor0Wj2kzs0hgoV8SbTOCEoQqrbUHc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Iez0dWCteMo9UekBdShFhLW0NI1kWQMcAVBOb6RNBlXqVq4pGaav3WfRhpG5JzsN1FK7pwwTv3hoIWXO+HN/woAG5+RgieemhBDPvWvtqlJx/khg8A+9QOzFJXp2d/OT0ceopZh1iMx7cT/yWCHxSQENacld/82zlSKnWDlC224= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linbit.com; spf=pass smtp.mailfrom=linbit.com; dkim=pass (2048-bit key) header.d=linbit-com.20230601.gappssmtp.com header.i=@linbit-com.20230601.gappssmtp.com header.b=lqev2ftq; arc=none smtp.client-ip=209.85.221.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linbit.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linbit.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linbit-com.20230601.gappssmtp.com header.i=@linbit-com.20230601.gappssmtp.com header.b="lqev2ftq" Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-437711e9195so3352438f8f.1 for ; Thu, 12 Feb 2026 07:01:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linbit-com.20230601.gappssmtp.com; s=20230601; t=1770908505; x=1771513305; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=+5IOSasBlsX0Zq7MQwRuynmqCbpOzr3vQNsDoSWsb48=; b=lqev2ftq/PYnJitIimWWg5gzKqLAXLI7REoSEr/nSjHtWKjGvTjqyK9pDBwsly/oyK iGJOPRIi8wSCCTmX/SdNgrm+1RxpZBmIuNeIFrGjj3kEbcUY4Cl0CEt97Jp/5ggp2PW7 vYGCXl1F4+qEESN74SsjPFpVyuSLyl/lskzDGRR2lGQB9rKoTqQBLa5v5MOrgC/Z1e9Z t9O8twCiQKsQsObeuWxojR0VdKsmw1T56tPy/YtMqtbx4tHhh51gMv0J/ohYbpaWAi0W 9y+RlXo85TLI2K+1WUy5um+254LJaYBCfC/FbapXMUgj4yVBB+1O6sllKlcFnZQ4X28h B2LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770908505; x=1771513305; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+5IOSasBlsX0Zq7MQwRuynmqCbpOzr3vQNsDoSWsb48=; b=M31Dn78pv9dpV/Te8v7xXdWZ7gIyYfeHEh5f3HVYbPwhjPdF2soLn48IsNSGbcrg47 rEYlS9HJE6orLJMUnOsXPY8B5BvgxRaeSiZO7kDDRyC2HwV/5+5AtR1GEH4eRCBeExv/ fYLjTxsExtHOcN0XGRIDXf6vo89k59dNtwNJqtegY6yc7r7sdXHbr58h4qQarEVvFYAS YZ8g4ExSDB/J0CcSosoz3MkWsDEWZAjbXOA0UXXfvkNGJgDcP2/SoU7Bj2w5babwWxqm EroIE41rqMlbSUImxXuyIS/IkiREepQ+qR1/BMggYSQOitRNEDf4uI/+Ks6hA/KEbFlv cTmA== X-Forwarded-Encrypted: i=1; AJvYcCVa5xC06hL54WiQU6eIDU7AzrvpMF63OaqZUIYMXROL92Hx6CkAPVOmXy6V8UkYgz9fiwz1Hh4RiaCDlRQ=@vger.kernel.org X-Gm-Message-State: AOJu0YyKFOKaEcHOoxC0yDkSALGLoMYVrSq41R0ZeGBeuxK2t/PFCHiM /TqG13LKQd2u7/v6KmOHprbaxXB+wau+T3k9wlx3orXfGChtkTPNPCfgcEFiox4QusM= X-Gm-Gg: AZuq6aKOli01dm3E+QPQJvPDEBSveADjUzqfqd3O2MYAWwCoz4Tu+zRjY+6Y5keIxfA ITo6jyfVGF3Qsfqg74a6pCgzmTrngQjnf8xaIKWiSBw7IYW7RDFdTFHmQGp4yoVgAxTbf9fc8uZ gOO/vSqiJxDWQqU6dkOFK+h0KKlwmnMw7i3LmdXZ3Uy3Eq4fFh8LFWksL4929E08dSNZLdW2TDk HECY8qc6hwderMpN5MiPAgFbFdPcegHRAVvSAsSfM/B/9H11aQUNLiwUkkaMeoc5j+Kgtrp0Wmj ogTfWeQ67cb3mIXp+ddqLRkm4nSU4XkgeNEcvvWL8suxMhNW4tLSxcVZaLQ9OFdRBHlZrr1qu/U VpJIRNEPeSUH5dfHNPCBeqnP55HUF1tmy9Kqnf44GXQ3A1TVwb4nNQuKX3LGutf2UcEIKTcIgN4 BiYmFhV/BC9pjFRgWXgCa2kqvtYkJp6WOjVIJG07+b7PrlIm23BIQXOKGA5kBOaF4sLbdL5s2gC e61+OfvQu1012p5A9YzmwvRlQ== X-Received: by 2002:a5d:5f84:0:b0:435:e436:7fb with SMTP id ffacd0b85a97d-4378acaba28mr5911570f8f.50.1770908505145; Thu, 12 Feb 2026 07:01:45 -0800 (PST) Received: from [192.168.178.55] (h082218028181.host.wavenet.at. [82.218.28.181]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43783e5be13sm12942474f8f.35.2026.02.12.07.01.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Feb 2026 07:01:44 -0800 (PST) Message-ID: Date: Thu, 12 Feb 2026 16:01:43 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] drbd: always set BLK_FEAT_STABLE_WRITES To: Christoph Hellwig Cc: Jens Axboe , drbd-dev@lists.linbit.com, linux-kernel@vger.kernel.org, Lars Ellenberg , Philipp Reisner , linux-block@vger.kernel.org References: <20260205173928.3166880-2-christoph.boehmwalder@linbit.com> From: =?UTF-8?Q?Christoph_B=C3=B6hmwalder?= Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Am 06.02.26 um 07:43 schrieb Christoph Hellwig: > On Thu, Feb 05, 2026 at 06:39:29PM +0100, Christoph Böhmwalder wrote: >> DRBD requires stable pages because it may read the same bio data >> multiple times for local disk I/O and network transmission, and in >> some cases for calculating checksums. >> >> The BLK_FEAT_STABLE_WRITES flag is set when the device is first >> created, but blk_set_stacking_limits() clears it whenever a >> backing device is attached. In some cases the flag may be >> inherited from the backing device, but we want it to be enabled >> at all times. > > This looks like a bug. If an underlying device requires > BLK_FEAT_STABLE_WRITES, the upper device needs to inherit it. The current block layer logic actually seems correct to me. The underlying device may or may not require stable writes, but regardless of that, DRBD itself definitely does need it. In blk_stack_limits, DRBD is the top device, and DRBD's backing disk is the bottom device. If the backing disk happens to require stable writes, this would indeed be correctly inherited. So the only missing logic is that DRBD still wants to enable stable writes for itself even if the backing disk does *not* request it. So it seems to me that this patch is the correct fix for DRBD's special case. Is it not supposed to work like that? -- Christoph Böhmwalder LINBIT | Keeping the Digital World Running DRBD HA — Disaster Recovery — Software defined Storage