[Linux-cluster] sparse-file clone breaks on GFS2
pbraun at nethence.com
Thu Sep 24 09:07:04 UTC 2020
>> It seem that 4.18.20 is missing the relevant parts of the following
>> 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.
Wow I was missing that message. I did not receive it nor it is
available online on the archive, it states `Message not available`.
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.
And then more recently over there (20 May 2020)
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
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
cp --sparse=always dummy.ext4 dummy-clone.ext4
md5sum dummy.ext4 dummy-clone.ext4
More information about the Linux-cluster