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

[Christoph Hellwig <hch@lst.de>]

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.