Re: [RESEND PATCH] dm-ebs: Mark full buffer dirty even on partial write

Benjamin Marzinski
2025-11-18T14:15:56Z

On Tue, Nov 18, 2025 at 01:00:36PM +0100, Mikulas Patocka wrote:
>
>
> On Tue, 18 Nov 2025, Uladzislau Rezki wrote:
>
> > Hello, Mikulas!
> >
> > > Hi
> > >
> > > What is the logical_block_size of the underlying nvme device? - i.e.
> > > what's the content of this file
> > > /sys/block/nvme0n1/queue/logical_block_size in the virtual machine?
> > >
> > It is 512. Whereas a physical is bigger, i.e. my device can not perform
> > I/O by 512 granularity.
>
> And what is physical block size? Is it 8192?
>
> > As for virtual machine, i just simulated the problem so people can set
> > it up and check. The commit message describes how it can be reproduced.
> >
> > The dm-ebs target which i setup does ebs to ubs conversion, so the NVME
> > driver gets BIOs are in size and aligned to ubs size. The ubs size
> > corresponds to the underlying physical device I/O size.
> >
> > So your patch does not work if logical < physical. Therefore it does
> > not help my project.
>
> Logical block size is the granularity at which the device can accept I/O.
> Physical block size is the block size on the medium.
>
> If logical < physical, then the device performs read-modify-write cycle
> when writing blocks that are not aligned at physical block size.
>
> So, your setup is broken, because it advertises logical block size 512,
> but it is not able to perform I/O at this granularity.

This emulated nvme device is broken, but the question still remains,
"should dm-ebs enfore writing at the alignment that was specified in its
table line?" If you don't specify a ubs in the table line, it defaults
to the logical block size. So, if you do specify a ubs, it stands to
reason that you want IO at that alignment, instead of the logical-block
size (perhaps because your device is broken, and advertises the wrong
logical block size).

So, I think that Uladzislau's patch makes sense, in addition to your
own.

-Ben

> There is this piece of code in include/linux/blkdev.h:
> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> /*
> * We should strive for 1 << (PAGE_SHIFT + MAX_PAGECACHE_ORDER)
> * however we constrain this to what we can validate and test.
> */
> #define BLK_MAX_BLOCK_SIZE SZ_64K
> #else
> #define BLK_MAX_BLOCK_SIZE PAGE_SIZE
> #endif
>
> /* blk_validate_limits() validates bsize, so drivers don't usually need to */
> static inline int blk_validate_block_size(unsigned long bsize)
> {
> if (bsize < 512 || bsize > BLK_MAX_BLOCK_SIZE || !is_power_of_2(bsize))
> return -EINVAL;
>
> return 0;
> }
>
> What happens when you define CONFIG_TRANSPARENT_HUGEPAGE in your .config?
> Does it fix the problem with small logical block size for you?
>
> Mikulas
>
> > --
> > Uladzislau Rezki
> >
>