From some old May 2017 email. I asked the following:
"From the docs, I see you can identify the shards by the GFID
# getfattr -d -m. -e hex/path_to_file/
# ls /bricks/*/.shard -lh | grep /GFID
Is there a gluster tool/script that will recreate the file?
or can you just sort them sort them properly and then simply cat/copy+
them back together?
cat shardGFID.1 .. shardGFID.X > thefile "
/
The response from RedHat was:
"Yes, this should work, but you would need to include the base file (the
0th shard, if you will) first in the list of files that you're stitching
up. In the happy case, you can test it by comparing the md5sum of the
file from the mount to that of your stitched file."
We tested it with some VM files and it indeed worked fine. That was
probably on 3.10.1 at the time.
-wk
On 4/20/2018 12:44 PM, Jamie Lawrence wrote:
Hello,
So I have a volume on a gluster install (3.12.5) on which sharding was enabled
at some point recently. (Don't know how it happened, it may have been an
accidental run of an old script.) So it has been happily sharding behind our
backs and it shouldn't have.
I'd like to turn sharding off and reverse the files back to normal. Some of
these are sparse files, so I need to account for holes. There are more than
enough that I need to write a tool to do it.
I saw notes ca. 3.7 saying the only way to do it was to read-off on the
client-side, blow away the volume and start over. This would be extremely
disruptive for us, and language I've seen reading tickets and old messages to
this list make me think that isn't needed anymore, but confirmation of that
would be good.
The only discussion I can find are these videos[1]:
http://opensource-storage.blogspot.com/2016/07/de-mystifying-gluster-shards.html
, and some hints[2] that are old enough that I don't trust them without
confirmation that nothing's changed. The video things don't acknowledge the
existence of file holes. Also, the hint in [2] mentions using
trusted.glusterfs.shard.file-size to get the size of a partly filled hole; that
value looks like base64, but when I attempt to decode it, base64 complains
about invalid input.
In short, I can't find sufficient information to reconstruct these. Has anyone
written a current, step-by-step guide on reconstructing sharded files? Or has
someone has written a tool so I don't have to?
Thanks,
-j
[1] Why one would choose to annoy the crap out of their fellow gluster users by
using video to convey about 80 bytes of ASCII-encoded information, I have no
idea.
[2] http://lists.gluster.org/pipermail/gluster-devel/2017-March/052212.html
_______________________________________________
Gluster-users mailing list
[email protected]
http://lists.gluster.org/mailman/listinfo/gluster-users
_______________________________________________
Gluster-users mailing list
[email protected]
http://lists.gluster.org/mailman/listinfo/gluster-users
