All of lore.kernel.org
 help / color / mirror / Atom feed
From: Uladzislau Rezki <urezki@gmail.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Uladzislau Rezki <urezki@gmail.com>,
	Mikulas Patocka <mpatocka@redhat.com>,
	Benjamin Marzinski <bmarzins@redhat.com>,
	Alasdair Kergon <agk@redhat.com>, DMML <dm-devel@lists.linux.dev>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mike Snitzer <snitzer@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RESEND PATCH] dm-ebs: Mark full buffer dirty even on partial write
Date: Mon, 24 Nov 2025 19:05:21 +0100	[thread overview]
Message-ID: <aSSeYQOl1db19yoJ@pc636> (raw)
In-Reply-To: <20251124170037.GA28939@lst.de>

On Mon, Nov 24, 2025 at 06:00:37PM +0100, Christoph Hellwig wrote:
> On Mon, Nov 24, 2025 at 04:30:25PM +0100, Uladzislau Rezki wrote:
> > > 
> > > > 
> > > > 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.
> 
> I'm still lost what the question is, sorry.
> 
No problem, i am fine with it.

Thank you for your input especially explaining the difference
between logical_block_size and physical_block_size for nvme device.

Appreciate it!

--
Uladzislau Rezki

  reply	other threads:[~2025-11-24 18:05 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-17 10:59 [RESEND PATCH] dm-ebs: Mark full buffer dirty even on partial write Uladzislau Rezki (Sony)
2025-11-17 20:48 ` Mikulas Patocka
2025-11-18 11:39   ` Uladzislau Rezki
2025-11-18 12:00     ` Mikulas Patocka
2025-11-18 12:40       ` Uladzislau Rezki
2025-11-18 12:46         ` Christoph Hellwig
2025-11-18 14:15       ` Benjamin Marzinski
2025-11-18 17:21         ` Mikulas Patocka
2025-11-19  5:46           ` Christoph Hellwig
2025-11-19  8:43             ` Uladzislau Rezki
2025-11-19  8:53               ` Christoph Hellwig
2025-11-19  8:57                 ` Uladzislau Rezki
2025-11-19  9:00                   ` Christoph Hellwig
2025-11-19  9:01                     ` Uladzislau Rezki
2025-11-19  9:05                       ` Christoph Hellwig
2025-11-19  9:13                         ` Uladzislau Rezki
2025-11-19  9:17                           ` Christoph Hellwig
2025-11-19 17:26             ` Mikulas Patocka
2025-11-20  6:21               ` Christoph Hellwig
2025-11-20 12:08                 ` Uladzislau Rezki
2025-11-20 12:40                   ` Uladzislau Rezki
2025-11-21  7:25                     ` Christoph Hellwig
2025-11-21  7:24                   ` Christoph Hellwig
2025-11-21 13:21                     ` Uladzislau Rezki
2025-11-21 16:48                       ` Benjamin Marzinski
2025-11-24 10:43                         ` Uladzislau Rezki
2025-11-24 14:30                       ` Christoph Hellwig
2025-11-24 15:30                         ` Uladzislau Rezki
2025-11-24 17:00                           ` Christoph Hellwig
2025-11-24 18:05                             ` Uladzislau Rezki [this message]
  -- strict thread matches above, loose matches on Subject: below --
2025-10-14 14:47 Uladzislau Rezki (Sony)
2025-10-16 19:59 ` Andrew Morton
2025-10-17 15:55   ` Uladzislau Rezki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aSSeYQOl1db19yoJ@pc636 \
    --to=urezki@gmail.com \
    --cc=agk@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=bmarzins@redhat.com \
    --cc=dm-devel@lists.linux.dev \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpatocka@redhat.com \
    --cc=snitzer@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.