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

Uladzislau Rezki
2025-11-20T12:09:02Z

On Thu, Nov 20, 2025 at 07:21:46AM +0100, Christoph Hellwig wrote:
> On Wed, Nov 19, 2025 at 06:26:13PM +0100, Mikulas Patocka wrote:
> >
> >
> > On Wed, 19 Nov 2025, Christoph Hellwig wrote:
> >
> > > On Tue, Nov 18, 2025 at 06:21:56PM +0100, Mikulas Patocka wrote:
> > > > OK - I accepted Uladzislau's patch. As logical block size and physical
> > > > block size seem to be unreliable, it's better to set the size in dm-ebs.
> > >
> > > logical and physical block size are reliable. Uladzislau just seems
> > > to have a completely broken device that needs fixing, because it will
> >
> > He created a qemu-emulated NVMe device with physical and logical block
> > size 8192 in a virtual machine. And logical block size was reported as 512
> > in the guest kernel - so it is either a qemu bug or a kernel bug.
>
> No, that's not the case. If you use his command line you'll see a qemu
> device with 8192 logical blocks assuming you have support for large
> folios, or a completely unusuable device that claims to have 512
> byte blocks for compatibility, but also a capacity of zero so that no
> one can use it for anything but passthrough.
>
> > in nvme_update_disk_info there is this piece of code:
> > if (blk_validate_block_size(bs)) {
> > bs = (1 << 9);
> > valid = false;
> > }
>
> Yes, that's what I mentioned above. The valid=false sets the capacity
> to zero, so you're not actually going to be able to use this device.
>
> > So, the valid block size depends on whether CONFIG_TRANSPARENT_HUGEPAGE is
> > defined, which is quite weird.
>
> And also the page size, and none of that is too weird. You need support
> efficiently allocating large order folios to support a
> block size > PAGE_SIZE and currently CONFIG_TRANSPARENT_HUGEPAGE is
> the guard for that. There was some talk of lifting that, but that
> requires a bit of work.
>
Could you please check below? Is the last one is correctly reported?
I have enabled the CONFIG_TRANSPARENT_HUGEPAGE option. If i specify,
8192, 8192 first case, reports are what i set. Second variant 512, 8129
shows 512, 512:

CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD=y
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set
# CONFIG_TRANSPARENT_HUGEPAGE_NEVER is not set

-device nvme,drive=drv0,serial=foo,logical_block_size=8192,physical_block_size=8192
urezki@pc638:~$ sudo nvme list
Node Generic SN Model Namespace Usage Format FW Rev
--------------------- --------------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1 /dev/ng0n1 foo QEMU NVMe Ctrl 1 8.49 GB / 8.49 GB 8 KiB + 0 B 10.0.6
urezki@pc638:~$ sudo cat /sys/block/nvme0n1/queue/logical_block_size
8192
urezki@pc638:~$ sudo cat /sys/block/nvme0n1/queue/physical_block_size
8192
urezki@pc638:~$

-device nvme,drive=drv0,serial=foo,logical_block_size=512,physical_block_size=8192
urezki@pc638:~$ sudo nvme list
Node Generic SN Model Namespace Usage Format FW Rev
--------------------- --------------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1 /dev/ng0n1 foo QEMU NVMe Ctrl 1 8.49 GB / 8.49 GB 512 B + 0 B 10.0.6
urezki@pc638:~$ sudo cat /sys/block/nvme0n1/queue/physical_block_size
512
urezki@pc638:~$ sudo cat /sys/block/nvme0n1/queue/logical_block_size
512
urezki@pc638:~$

Is that what should be reported?

--
Uladzislau Rezki