On 11/04/2024 20:07, Luis Chamberlain wrote:
So if you
have a 4K PBS and 512B LBS, then WRITE_ATOMIC_16 would be required to write
16KB atomically.
Ugh. Why does SCSI requires a special command for this?
The actual question from others is why does NVMe not have a dedicated
command for this, like:
https://lore.kernel.org/linux-nvme/20240129062035.GB19796@xxxxxx/
It's a data integrity feature, and we want to know if it works properly.
Now we know what would be needed to bump the physical block size, it is
certainly a different feature, however I think it would be good to
evaluate that world too. For NVMe we don't have such special write
requirements.
I put together this kludge with the last patches series of LBS + the
bdev cache aops stuff (which as I said before needs an alternative
solution) and just the scsi atomics topology + physical block size
change to easily experiment to see what would break:
https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=20240408-lbs-scsi-kludge
Using a larger sector size works but it does not use the special scsi
atomic write.
If you are using scsi_debug driver, then you can just pass the desired
physblk_exp and sector_size args - they both default to 512B. Then you
don't need bother with sd.c atomic stuff, which I think is what you want.
To me, O_ATOMIC would be required for buffered atomic writes IO, as we want
a fixed-sized IO, so that would mean no mixing of atomic and non-atomic IO.
Would using the same min and max order for the inode work instead?
Maybe, I would need to check further.
I'd be happy to help review too.
Yeah, I'm starting to think that min and max inode would make life
easier, as we don't need to deal with the scenario of an atomic write to
a folio > atomic write size.
Thanks,
John
