[GEDI] Strange data corruption issue with gluster (libgfapi) and ZFS

[Stefan Ring]

On Fri, Feb 28, 2020 at 12:10 PM Kevin Wolf <kwolf at redhat.com> wrote:
> >
> > 8700
> >   grows the file to a certain size (2134144 blocks)
> >
> > <8700 retires, nothing in flight>
> >
> > 8701
> >   writes 55 blocks inside currently allocated file range, close to the
> > end (7 blocks short)
> >
> > 8702
> >   writes 54 blocks from the end of 8701, growing the file by 47 blocks
> >
> > <8702 retires, 8701 remains in flight>
> >
> > 8703
> >   writes from the end of 8702, growing the file by 81 blocks
> >
> > <8703 retires, 8701 remains in flight>
> >
> > 8704
> >   writes 1623 blocks also from the end of 8702, growing the file by 1542 blocks
> >
> > <8701 retires>
> > <8704 retires>
> >
> > The exact range covered by 8703 ends up zeroed out.
> >
> > If 8701 retires earlier (before 8702 is issued), everything is fine.
>
> This sounds almost like two other bugs we got fixed recently (in the
> QEMU file-posix driver and in the XFS kernel driver) where two write
> extending the file size were in flight in parallel, but if the shorter
> one completed last, instead extending the file, it would end up
> truncating it.
>
> I'm not sure, though, why 8701 would try to change the file size because
> it's entirely inside the already allocated file range. But maybe adding
> the current file size at the start and completion of each request to
> your debug output could give us more data points?

Something I did not notice initially: Both 8700 and 8701 write to the
same starting offset. That does not change the fact that 8701 should
not change the size of the file.