From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) (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 2E178313E01 for ; Mon, 24 Nov 2025 15:30:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763998231; cv=none; b=p3TBNY7ts1Ean/kMrnxA+POepXBp8cJnvNXq6FOVDqKHqTLoIXe8RtO84e8UJA2di3ainKcvhc4k+tkfTygyNL60B4EBQEBO3vbVO2QlfWMmm6IKutC5AWMBv/EZ/rwM5/mTyIKKgu+lmCiWBOim0hMJYYYW4PO7We3GXE9Ucqg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763998231; c=relaxed/simple; bh=Koq7nupbyqygWfTt3eJxA8tO65rwhAKyZcUDi0cV4pg=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=X90vxA/15OfjefboYWMtqFHfeXPEBeHWI5v5neQcihnewKo4JemYptEFE/2zraGGrG3vgLIrc35y6eUpUJkblx2YKS+bXXA6611KscVSt+PH9RZEUp0AVER71vkZT7fnzTxlvBHOUKo7dddmU1jInXUn6GMtxbEZOEwvDRg9m88= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=AcKM4FSt; arc=none smtp.client-ip=209.85.167.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="AcKM4FSt" Received: by mail-lf1-f54.google.com with SMTP id 2adb3069b0e04-591c98ebe90so5497482e87.3 for ; Mon, 24 Nov 2025 07:30:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763998228; x=1764603028; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=jpAZicEbV7PF1omS+qtAKskwicXqde/8+NG+Ffv60ro=; b=AcKM4FStB4nyDSRD5AHUlLI6TOMPq24ezqOE7gt4oaM6kMFISYrEC2KofuB9naXDIa aIlFbnXWzb9gIQd6o06YjGUvjLxwcF+PqCuWq8JN7jofOzjEcOLOAtHKnZiKzfD05ATG OgISi4JL3XaqitvYo1sJlk4xn05cWcsFb/ZetoFdRLXKCRena0bBuYI5JvXPaNIJu8+6 llhP7uE6q/CrjSPgD5jkyJfUrv+7tlY5m4lb5IHZmcmShd+lLTvj9lIuZhNdO54W+WZd 7UhmECS+Bkxx5V5uKu1fl4itUhsOlXSz7vH/zm1An7lH3xLvS1ZUStXyrXzR4UeXkVQT 4rjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763998228; x=1764603028; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jpAZicEbV7PF1omS+qtAKskwicXqde/8+NG+Ffv60ro=; b=iIxpwkN0AGgNpInrxvyfb9PJ4co2PPEsHiyAfSh/fPSHD/+qlMEOYtow9qVCcOAraS GN5PRnNrU3eNYDPXj5TsdcGC99pHVlM1u7xOtpqwhFwgQojyROfgnD+rANQfCcXqdmfx l9hZcfQUeVHXqrLz/zLUSEXgQerzdC7tD2TIfmbL4SsYRGR/euBOb+qYwuGEuaTcRsAU Y9lwDPN0ohsM8wjO4t4YT7NEGOyYpNjeMfGEGFNwS38Xsaww59jfXUoQ/fezDWbufkcA /szYUopfz3aELOaAETYniPkW2JPqYIKfyZyN+47wWQVfD96AAUjyjkn0j9mLpHjhcJ/n hQMw== X-Forwarded-Encrypted: i=1; AJvYcCV6zu7LMoeGEK8NOJI0U11RobxgoBe39/rQELR9AxbctReGFnnHx9HIBw8442RKzFxczFN7ZFSQDwe7QJQ=@vger.kernel.org X-Gm-Message-State: AOJu0Yy4ye75st2mdgW6bCXBAtitPJqBtUl3WokE7Os3Vv1stdIvwpdq w6gauXjFpAWIKU79rYwMdpGDfox4+6FSIYIrLI//22x5+bgtlKT3PW2N X-Gm-Gg: ASbGncuorAGoUOGwNWhKQGpXMtnxciAnmDqCgfQZi8wq3hPMOow0MaC0xKUKKnoRcdr uGVZt/gkzUMSo62gwV344aDBk1valkf8l4bIWFE4C2YiJ25m32RiGArWZHuUZgBamLBpWRcUUkk YzONhVj+3iPulgzzZ4qn+UJC7Fhr7qhppMUqNcf7GgupJ10LebtmhgZgOPadLl09NcE1mX66xZS /SgV9ZQrWYwkZucuw5mq0g2i54gYeoXLQFmRZ9u5JtfWugVUTM9lnGeFRn5ClbttUA/APP+ooca o8JSr7i0mbbDe+4X1NyBtA+XB26Z/7inKWOzh7k/+YJanu1ziGwgVZN2CWTxy948GXp2vs+PzbG iHphO+/hYKzJcBmbzlLrWRH31mtPBvNHgZgvKSXPChrgWXvdgJICnurRDVRY2GWgm6KT6Gv61YN 974otFkis6TcqpydphOEBbdmmRLHsM17tEeCfD7g== X-Google-Smtp-Source: AGHT+IHpw1eJsk3wPrlTtylJwn1r6J3I3D/XS7hNtlwwly7OqIZfysgrEcwxi6bY2FA0tx6gjqCoww== X-Received: by 2002:a05:6512:1154:b0:595:7876:7b78 with SMTP id 2adb3069b0e04-596a3eac7edmr4153498e87.15.1763998227833; Mon, 24 Nov 2025 07:30:27 -0800 (PST) Received: from pc636 (host-95-203-18-135.mobileonline.telia.com. [95.203.18.135]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-596a710f00dsm2456626e87.0.2025.11.24.07.30.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Nov 2025 07:30:27 -0800 (PST) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Mon, 24 Nov 2025 16:30:25 +0100 To: Christoph Hellwig Cc: Uladzislau Rezki , Mikulas Patocka , Benjamin Marzinski , Alasdair Kergon , DMML , Andrew Morton , Mike Snitzer , LKML Subject: Re: [RESEND PATCH] dm-ebs: Mark full buffer dirty even on partial write Message-ID: References: <73556fc8-5fbf-37cb-26b9-7cdb88f69720@redhat.com> <230baa83-cd79-f232-5fb8-1476115e1ae7@redhat.com> <20251119054635.GB19993@lst.de> <20251120062146.GA29990@lst.de> <20251121072421.GA29754@lst.de> <20251124143044.GA17164@lst.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20251124143044.GA17164@lst.de> On Mon, Nov 24, 2025 at 03:30:44PM +0100, Christoph Hellwig wrote: > On Fri, Nov 21, 2025 at 02:21:34PM +0100, Uladzislau Rezki wrote: > > - offset &= -DM_BUFIO_WRITE_ALIGN; > > - end += DM_BUFIO_WRITE_ALIGN - 1; > > - end &= -DM_BUFIO_WRITE_ALIGN; > > + align = max(DM_BUFIO_WRITE_ALIGN, bdev_logical_block_size(b->c->bdev)); > > + offset &= -align; > > + end += align - 1; > > + end &= -align; > > if (unlikely(end > b->c->block_size)) > > end = b->c->block_size; > > > > > > and it fixes the setup which i described in the commit message, but i > > have question. > > And this patch, using bdev_logical_block_size looks correct. > > > > > Why in dm-ebs we need to offload partial buffer < ubf size? > > I don't understand this question. What is ubf? What does partial > buffer mean in this context, and what does offload mean? > That was a typo :) i meant ubs - which is underlying block size or number of sectors which define the logical block size of the device. In our case it is 8K thus is 16 = 512 * 16 = 8K. Partial buffer means, in context of dm-ebs, that within 8K buffer only part of it can be modified. For example, since we emulate 512B to 8K from upper layer to the device, a file system can write for example just first 4K within 8K window buffer and only that part is marked as dirty. offloading or imposing the data to the lower layer. i.e. writing dirty buffers to the device calling submit_io(). Is it better? It might be that i missed something, feel free to correct. -- Uladzislau Rezki