[Gluster-users] Inconsistent Shard linking
lindsay.mathieson at gmail.com
Sat May 14 04:28:43 UTC 2016
This is the reason behind my earlier questions re replacing a node.
I had *yet another* disk failure. However I have now replaced all
desktop drives on the server (WD Blacks & Blues) with WD reds which are
rated for 24/7 NAS operation. Two nodes are 4*WD red in Zfs Raid10, one
node has 8 SAS drives in raid 10.
However :( the ZFS resilver on node vng revealed data corruption in one
However checking its hard link, its not linked to a data file, rather to
what was presumably a shard of the data file
find . -inum 291341
Checking the shard directory, there are 1024 64MB
"719041d0-d755-4bc6-a5fc-6b59071fac17.*" files. Checking the actually
gluster mount, there are no files with a gfid of
"719041d0-d755-4bc6-a5fc-6b59071fac17". All three nodes are the same in
1. I'm not to concerned about it as it seems to be a result of
straight out undetected disk corruption, a result of a crappy setup on
our part, since corrected.
2. I have no idea as to what image file was originally represented by
these shards or if its possible to find out. After a quick check they
all appear to be ok.
3. Not sure what to do about it - should I just delete the shards?
Or a broader note, I contemplating putting together some scripts to do
basically integrity checks on a sharded setup:
- Check for orphaned shards
- check for files missing shards (is it possible)
- Anything else?
I'd also like to write a service (c/c++) that can do an online scrub
(md5 check) of shards. Would that be possible via the gfapi or is to
high level for that?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-users