<html><head></head><body><div>You must have been running a really old version of glusterfs, 2 node systems haven't been supported for a few major releases now. if you want n-1 reliability you need at least a 4 node system.</div><div>On the bright side setup your new gluster system with approriate storage. Gluster doesn't do anything fancy with the data, it's all meta data magic, so trying to get a new modern glusterfs system to adopt your old bricks isn't worth the effort.</div><div>This is one of my bricks that I keep audio files on</div><div> z /gfss/brkaudio/</div><div>drwxr-xr-x. 8 root root 93 Dec 31 1969 /gfss/brkaudio/audio</div><div><br></div><div># z /gfss/brkaudio/audio/</div><div>drwxr-xr-x. 5 root root 39 Dec 27 2019 /gfss/brkaudio/audio/music</div><div>drwxr-xr-x. 4 root root 28 Dec 27 2019 /gfss/brkaudio/audio/speech</div><div>drwxr-xr-x. 2 root root 6 Oct 15 2016 /gfss/brkaudio/audio/words</div><div>drwxrwxrwt. 2 root root 6 Jul 28 2020 /gfss/brkaudio/audio/work</div><div><br></div><div>This is where the meta data magic is, its all based on inode number</div><div># ls -ald /gfss/brkaudio/audio/.*</div><div>drwxr-xr-x. 8 root root 93 Dec 31 1969 /gfss/brkaudio/audio/.</div><div>drwxr-xr-x. 3 root root 19 Dec 20 2019 /gfss/brkaudio/audio/..</div><div>drw-------. 263 root root 8192 Jul 18 2021 /gfss/brkaudio/audio/.glusterfs</div><div>drwxr-xr-x. 3 root root 25 Dec 27 2019 /gfss/brkaudio/audio/.trashcan</div><div><br></div><div>the way to recreate it is flip a coin pick your best bricks copy the data to the new gluster volumes, let it replicate. Then write a script with find to do compares with the second bricks data with the current new gluster data and figure out the problems.</div><div><br></div><div>Been there and done that.</div><div><br></div><div>On Sat, 2023-08-12 at 00:46 -0400, Richard Betel wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr">I had a small cluster with a disperse 3 volume. 2 nodes had hardware failures and no longer boot, and I don't have replacement hardware for them (it's an old board called a PC-duino). However, I do have their intact root filesystems and the disks the bricks are on. <br><br>So I need to rebuild the cluster on all new host hardware. does anyone have any suggestions on how to go about doing this? I've built 3 vms to be a new test cluster, but if I copy over a file from the 3 nodes and try to read it, I can't and get errors in /var/log/glusterfs/foo.log:<br>[2023-08-12 03:50:47.638134 +0000] W [MSGID: 114031] [client-rpc-fops_v2.c:2561:client4_0_lookup_cbk] 0-gv-client-0: remote operation failed. [{path=/helmetpart.scad}, {gfid=00000000-0000-0000-0000-000000000000}<br>, {errno=61}, {error=No data available}]<br>[2023-08-12 03:50:49.834859 +0000] E [MSGID: 122066] [ec-common.c:1301:ec_prepare_update_cbk] 0-gv-disperse-0: Unable to get config xattr. FOP : 'FXATTROP' failed on gfid 076a511d-3721-4231-ba3b-5c4cbdbd7f5d. Pa<br>rent FOP: READ [No data available]<br>[2023-08-12 03:50:49.834930 +0000] W [fuse-bridge.c:2994:fuse_readv_cbk] 0-glusterfs-fuse: 39: READ => -1 gfid=076a511d-3721-4231-ba3b-5c4cbdbd7f5d fd=0x7fbc9c001a98 (No data available)<br><br>so obviously, I need to copy over more stuff from the original cluster. If I force the 3 nodes and the volume to have the same uuids, will that be enough?</div><div>________<br></div><div><br></div><div><br></div><div><br></div><div>Community Meeting Calendar:<br></div><div><br></div><div>Schedule -<br></div><div>Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC<br></div><div>Bridge: <a href="https://meet.google.com/cpu-eiue-hvk">https://meet.google.com/cpu-eiue-hvk</a><br></div><div>Gluster-users mailing list<br></div><div><a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br></div><div><a href="https://lists.gluster.org/mailman/listinfo/gluster-users">https://lists.gluster.org/mailman/listinfo/gluster-users</a><br></div></blockquote><div><br></div><div><span></span></div></body></html>