On Mon, 6 Jan 2025, John Garry wrote: > On 06/01/2025 17:26, Mike Snitzer wrote: > > On Mon, Jan 06, 2025 at 12:41:14PM +0000, John Garry wrote: > > > This series introduces initial device mapper atomic write support. > > > > > > Since we already support stacking atomic writes limits, it's quite > > > straightforward to support. > > > > > > Only dm-linear is supported for now, but other personalities could > > > be supported. > > > > > > Patch #1 is a proper fix, but the rest of the series is RFC - this is > > > because I have not fully tested and we are close to the end of this > > > development cycle. > > In general, looks reasonable. But I would prefer to see atomic write > > support added to dm-striped as well. Not that I have some need, but > > because it will help verify the correctness of the general stacking > > code changes (in both block and DM core). > > That should be fine. We already have md raid0 support working (for atomic > writes), so I would expect much of the required support is already available. BTW. could it be possible to add dm-mirror support as well? dm-mirror is used when the user moves the logical volume to another physical volume, so it would be nice if this worked without resulting in not-supported errors. dm-mirror uses dm-io to perform the writes on multiple mirror legs (see the function do_write() -> dm_io()), I looked at the code and it seems that the support for atomic writes in dm-mirror and dm-io would be straightforward. Another possibility would be dm-snapshot support, assuming that the atomic i/o size <= snapshot chunk size, the support should be easy - i.e. just pass the flag REQ_ATOMIC through. Perhaps it could be supported for dm-thin as well. Mikulas
