>> cd573cfaace07e7949bc0c46028904ff  /root/dummy-on-ext4.ext4
>> cd573cfaace07e7949bc0c46028904ff  /data2/dummy-clone-from-ext4.ext4
>>
>> and... WOW!  Cloning it yet again, it finally remains intact!
>>
>> cd573cfaace07e7949bc0c46028904ff  dummy-clone-from-ext4-and-clone.ext4
>> cd573cfaace07e7949bc0c46028904ff  dummy-clone-from-ext4.ext4
>>
>> It's strange.  Anyone?
>
> Absolutely. Really strange.

It truly happened, however when I try this again, I cannot reproduce this right now. All I see now is a corruption whenever I copy a sparse file-system from GFS2, be it created on EXT4 or not.

dd if=/dev/zero of=/root/dummy.ext4 bs=1G count=0 seek=1
mkfs.ext4 /root/dummy.ext4
cp --sparse=always /root/dummy.ext4 /data2/dummy-clone-from-ext4.ext4
cp --sparse=always /data2/dummy-clone-from-ext4.ext4 /data2/dummy-clone-from-ext4-clone.ext4 cp --sparse=always /data2/dummy-clone-from-ext4.ext4 /root/dummy-clone-from-gfs2.ext4 md5sum /root/dummy.ext4 /data2/dummy-clone-from-ext4.ext4 /data2/dummy-clone-from-ext4-clone.ext4 /root/dummy-clone-from-gfs2.ext4

gives

aefedffac2f2cbc0d8fe15155703e7a0  /root/dummy.ext4
aefedffac2f2cbc0d8fe15155703e7a0  /data2/dummy-clone-from-ext4.ext4
a3da5ced2af823e06a352124b9c800c7  /data2/dummy-clone-from-ext4-clone.ext4
a3da5ced2af823e06a352124b9c800c7  /root/dummy-clone-from-gfs2.ext4

and it's consistent, as shown with this second run:

be123782b303fc391f93478063d21b51  /root/dummy.ext4
be123782b303fc391f93478063d21b51  /data2/dummy-clone-from-ext4.ext4
22fa85945a94001089740f024a4c3f1e  /data2/dummy-clone-from-ext4-clone.ext4
22fa85945a94001089740f024a4c3f1e  /root/dummy-clone-from-gfs2.ext4

same happens with XFS sparse file:

dd if=/dev/zero of=/root/dummy.xfs bs=1G count=0 seek=1
mkfs.xfs /root/dummy.xfs
cp --sparse=always /root/dummy.xfs /data2/dummy-clone-from-ext4.xfs
cp --sparse=always /data2/dummy-clone-from-ext4.xfs /data2/dummy-clone-from-ext4-clone.xfs cp --sparse=always /data2/dummy-clone-from-ext4.xfs /root/dummy-clone-from-gfs2.xfs md5sum /root/dummy.xfs /data2/dummy-clone-from-ext4.xfs /data2/dummy-clone-from-ext4-clone.xfs /root/dummy-clone-from-gfs2.xfs

324c660d154cad3dd35f69a8531fc290  /root/dummy.xfs
324c660d154cad3dd35f69a8531fc290  /data2/dummy-clone-from-ext4.xfs
2e58d6e15a01ef3cf31b89e0ff219c7a  /data2/dummy-clone-from-ext4-clone.xfs
2e58d6e15a01ef3cf31b89e0ff219c7a  /root/dummy-clone-from-gfs2.xfs

and thankfully this does not happen with a sparse-file without a file-system on it, namely, full of _only_ zeroes:

dd if=/dev/zero of=/data2/dummy bs=1G count=0 seek=1
cp --sparse=always /data2/dummy /data2/dummy-clone
md5sum /data2/dummy /data2/dummy-clone

cd573cfaace07e7949bc0c46028904ff  /data2/dummy
cd573cfaace07e7949bc0c46028904ff  /data2/dummy-clone

cd573cfaace07e7949bc0c46028904ff  /data2/dummy
cd573cfaace07e7949bc0c46028904ff  /data2/dummy-clone

hexdump -C /data2/dummy
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
40000000

I will try to do other tests with self-forged data plus some sparse and see how it goes. I doubt it's related to something file-system-on-gfs2 specific.

>> In case it matters, I am using vanilla Linux 4.18.20 and not the RHEL
>> nor CentOS with patches.
>
> What distribution are you using (Slackware)? Any additional data about
> your filesystem (ie: num journals/nodes)? I would like to try to
> replicate the issue if I can find some spare time...
Slackware current with a hopefully close-enough kernel version as RHEL8 + gfs2-utils and dlm *1 but I suppose it can be reproduced with RHEL8. Actually I would prefer if you could reproduce the issue with a rather classical setup. I would make my case easier to defend ;-)

GFS2 file-system was created as such: `mkfs.gfs2 -j2 -t pro5s:data2 /dev/drbd2`, running on two DRBD8 dual-primary nodes. I still have no idea at what storage layer I am having troubles with here, so I also tested with a single mount on node2. And I also tested while having node1 as secondary. No success there and it's actually good news for me, as I wouldn't like my infrastructure to be f&^%ed up at the block-device level.

# mkfs.gfs2 -V
mkfs.gfs2 master (built Aug 16 2020 21:36:57)
Copyright (C) Red Hat, Inc.  2004-2010  All rights reserved.

oops, I should not be using the development branch so I switched to the release, but no big surprise, copying an EXT4 sparse file from GFS2, still corrupts it, here.

# mkfs.gfs2 -V
mkfs.gfs2 3.3.0 (built Sep 20 2020 19:28:37)
Copyright (C) Red Hat, Inc.  2004-2020  All rights reserved.

# dlm_controld -V
dlm_controld 4.0.9 (built Aug 17 2020 07:02:31)
Copyright Red Hat, Inc. 2004-2013

# tunegfs2 -l /dev/drbd2
tunegfs2 (Aug 16 2020 21:36:58)
File system volume name: pro5s:data2
File system UUID: 6a95be71-e865-4706-b7c8-0c1bb0c3e232
File system magic number: 0x1161970
Block size: 4096
Block shift: 12
Root inode: 66241
Master inode: 32854
Lock protocol: lock_dlm
Lock table: pro5s:data2

I am looking forward to hearing from you or anyone with a GFS2 mount in place, who's willing to reproduce the issue. Here are sample command lines on how to reproduce, meanwhile I try with something else than some mkfs.

dd if=/dev/zero of=dummy.xfs bs=1G count=0 seek=1
mkfs.xfs dummy.xfs
cp --sparse=always dummy.xfs dummy-clone.xfs
md5sum dummy.xfs dummy-clone.xfs

*1 https://pagure.io/gfs2-utils https://pagure.io/dlm

BR
-elge

--
Linux-cluster mailing list
Linux-cluster@redhat.com
https://www.redhat.com/mailman/listinfo/linux-cluster

Reply via email to