On Thu, 24 Feb 2022, Nitesh Shetty wrote: > On Wed, Feb 16, 2022 at 08:51:08AM -0500, Mikulas Patocka wrote: > > > > > > On Mon, 7 Feb 2022, Nitesh Shetty wrote: > > > > > Before enabling copy for dm target, check if underlaying devices and > > > dm target support copy. Avoid split happening inside dm target. > > > Fail early if the request needs split, currently spliting copy > > > request is not supported > > > > > > Signed-off-by: Nitesh Shetty <nj.shetty@xxxxxxxxxxx> > > > > If a dm device is reconfigured, you must invalidate all the copy tokens > > that are in flight, otherwise they would copy stale data. > > > > I suggest that you create a global variable "atomic64_t dm_changed". > > In nvme_setup_copy_read you copy this variable to the token. > > In nvme_setup_copy_write you compare the variable with the value in the > > token and fail if there is mismatch. > > In dm.c:__bind you increase the variable, so that all the tokens will be > > invalidated if a dm table is changed. > > > > Mikulas > > > > > Yes, you are right about the reconfiguration of dm device. But wouldn't having a > single global counter(dm_changed), will invalidate for all in-flight copy IO's > across all dm devices. Is my understanding correct? > > -- > Nitesh Shetty Yes, changing it will invalidate all the copy IO's. But invalidating only IO's affected by the table reload would be hard to achieve. Mikulas
