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>
