[Gluster-users] Reconstructing files from shards

[Krutika Dhananjay]

The short answer is - no there exists no script currently that can piece
the shards together into a single file.

Long answer:
IMO the safest way to convert from sharded to a single file _is_ by copying
the data out into a new volume at the moment.
Picking up the files from the individual bricks directly and joining them,
although fast, is a strict no-no for many reasons - for example, when you
have a replicated volume
and the good copy needs to be carefully selected and must remain a good
copy through the course of the copying process. There could be other
consistency issues with
file attributes changing while they are being copied. All of this is not
possible, unless you're open to taking the volume down.

Then the other option is to have gluster client (perhaps in the shard
translator itself)) do the conversion in the background within the gluster
translator stack, which is safer
but would require that shard lock it until the copying is complete. And
until then no IO can happen into this file.
(I haven't found the time to work on this, as there exists a workaround and
I've been busy with other tasks. If anyone wants to volunteer to get this
done, I'll be happy to help).

But anway, why is copying data into new unsharded volume disruptive for you?

-Krutika


On Sat, Apr 21, 2018 at 1:14 AM, Jamie Lawrence <jlawrence at squaretrade.com>
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
> Gluster-users at gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20180427/caa8148a/attachment.html>