[PATCH v2 08/10] dm: Add support for copy offload.
Mikulas Patocka
mpatocka at redhat.com
Fri Feb 25 01:12:31 PST 2022
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 at samsung.com>
> >
> > 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
More information about the Linux-nvme
mailing list