Gluster users - Aug 2013 - Removing files directly on bricks in 3.3

Up front, I'm going to say: you probably shouldn't do this.  If you need
to
remove a file, just rm it from a client and not directly on the brick.

If, however, you're like me, and you have garbage files generated during a
gluster crash, you may need to do some cleanup to restore correct operation
of your storage cluster.

At first, I just removed files.  Mysteriously, even after removing a file
from all bricks, it would come back after a few minutes!

Then I read
http://joejulian.name/blog/what-is-this-new-glusterfs-directory-in-33/ --
that explains why this was happening.

Here's a quick and dirty script to remove a file directly on a brick.
 YMMV, it's not my fault if your server catches fire while running this,
caveat emptor, etc., etc.

To run this, cd over to your brick top-level (the parent of the .glusterfs
dir) and issue a command like:

~/glusterrm.sh "path/to/my/file.name" --noop

The --noop (or, for that matter, any second parameter) will tell you what
it would remove but not remove anything.

If you're satisfied with the result, run

~/glusterrm.sh "path/to/my/file.name"

and the file will be deleted along with its shadow copy in the .glusterfs
dir.  Make sure you run the same sequence on any replicas, and your file is
gone, gone, gone.

#!/bin/bash
FILE="$1"

hidden_file_path=$(getfattr -m gfid -d -e hex "$FILE" |\
sed -n
'2s/.*0x\(..\)\(..\)\(....\)\(....\)\(....\)\(....\)\(............\)/\1\/\2\/\1\2\3-\4-\5-\6-\7/p')

NOOP=$2

if [ "x$NOOP" = "x" ] ; then
  rm -v .glusterfs/$hidden_file_path "$FILE"
else
  echo "Would remove the following:"
  echo .glusterfs/$hidden_file_path
  echo "$FILE"
fi


-- 
Justin Dossey
CTO, PodOmatic
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://supercolony.gluster.org/pipermail/gluster-users/attachments/20130801/6eddf09a/attachment.html>