[Linux-cluster] sparse-file clone breaks on GFS2

Pierre-Philipp Braun 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 
>> 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`.


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)
Linux 5.4.42

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
mkfs.ext4 dummy.ext4
cp --sparse=always dummy.ext4 dummy-clone.ext4
md5sum dummy.ext4 dummy-clone.ext4

More information about the Linux-cluster mailing list