Re: thin pool powerfail tests and data loss

On Mon, Sep 9, 2024 at 6:57=E2=80=AFPM Zdenek Kabelac <zdenek.kabelac@gmail=
.com> wrote:
>
> Dne 08. 09. 24 v 3:37 Lakshmi Narasimhan Sundararajan napsal(a):
> > Hi Team,
> > Greetings!
> >
> > In my experiments with thin pool and power cycle tests, I find that
> > the inflight data has not been persisted, even if there is a sync
> > following write that got completed.
> >
> > suppose we have the following bdev stackup:
> > bdevs(multi) -> mpath -> lvm pv -> lvm vg -> lvm thin pool -> multiple
> > thin vols.
> >
> > Each of the thin vols that has inflight data, has a corresponding sync
> > checkpoint periodically. The expectation is all writes before the sync
> > are persisted to disk and can survive power reset tests.
> >
> > Like below seq on many thin vols on the thin pool.
> > write -> write -> write -> fsync(fd) -> write -> write -> fsync(fd) -> =
..etc
> >
> > Now my code only does a fsync(fd) on the thin volume (block device dire=
ctly).
> > There are no fs mounts on the volume.
> > Is this sufficient or should the thin pool (/dev/mapper/pool) also be
> > synced along?
> > What would be the proper sequence of sync actions to survive a power re=
set?
> >
> > I am also trying to validate if this is an issue because mpath is
> > involved in any way(another dm layer in between), but would appreciate
> > some guidance in this
> > regard.
>
> Hi
>
> Could you please retest your issue with  recent lvm2  (>=3D 2.03.24) and =
recent
> linux kernel   >=3D 6.9

Thank you for your quick attention.

That is a big jump.
Would you be willing to consider any distro (say OCP latest?), that
will come with a bundle for both lvm+kernel, is there any such
combination you would consider for this test?
Also, is there any way I can check issues/fixes of interest?

Is my logic using fsync(thin pool device) sufficient to pass power fail tes=
ts?
Are there any stronger versions or more logic to ensure power reset test pa=
sses?

Regards

>
> Regards
>
> Zdenek
>