It seem that 4.18.20 is missing the relevant parts of the following
fixes:
a27a0c9b6a2 ("gfs2: gfs2_walk_metadata fix")
566a2ab3c90 ("gfs2: Another gfs2_walk_metadata fix")
Without those fixes, lseek SEEK_HOLE/SEEK_DATa will sometimes report
garbage, and so cp doesn't know what to copy.
Andreas
Wow I was missing that message. I did not receive it nor it is
available online on the archive, it states `Message not available`.
https://www.redhat.com/archives/linux-cluster/2020-September/thread.html
Any idea why? I also wonder how Gionatan could receive it.
Yes that did the trick, thank you very much Andreas, for your patches
and your (hidden) answer.
Well, I was just sitting down to create two CentOS 8.2 box for testing,
but I really think this explains the issue reported by Pierre-Philipp.
Thanks so much for these valuable information!
Can you confirm that RHEL 8.x includes the above patches?
I found those two patches referenced in the source RPM spec indeed.
That's still the 4.18.0 kernel.
https://git.centos.org/rpms/kernel/blob/c8s/f/SPECS/kernel.spec
And then more recently over there (20 May 2020)
Linux 5.4.42
https://lwn.net/Articles/820973/
So I could finally handle sparse file alright with the aforementioned
version. It's a pity I was stuck with some bug-or-incompatibility with
version 5.4.58 last month
(https://www.redhat.com/archives/linux-cluster/2020-August/msg00000.html):
I was so close to working version already. Thing is, it was probably
the latest longterm kernel release available at that time. Today's
longterm version is 5.4.67 and I avoided it. I tried stable Linux 5.8.x
instead, and it's a success. I am finally enjoying happy virtual disks
on GFS2 and from all nodes.
Here again and for the record, the sparse-file check,
dd if=/dev/zero of=dummy.ext4 bs=1GB count=0 seek=1
mkfs.ext4 dummy.ext4
cp --sparse=always dummy.ext4 dummy-clone.ext4
md5sum dummy.ext4 dummy-clone.ext4
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
