On 11/16/2013 04:20 AM, Emmanuel Dreyfus wrote:
Anand Avati <avati@xxxxxxxxxxx> wrote:
Regarding your concern about complications while healing - we
should change our "manual fixing" instructions to:
- go to backend, access through gfid path or normal path - rmxattr
the afr changelogs - truncate the file to 0 bytes (like ">
filename")
What about a adding a gluster command like this? gluster rm path [-r]
[-b brick|-a] -r recursive -b specify brick, use relative path to
find if not specified -a remove on all other bricks
That could even help removing files in non split-brain scenarios,
where it takes age because rm -rf goes through several FOPs for each
file.
Actually, it might be even better if we had a command to bless/promote a
single copy of the file and delete/truncate *all others* instead of
having to do them one at a time. I submitted a patch a while ago to do
something like this.
http://review.gluster.org/#/c/4132/
This is going to be strictly necessary some day, as we stop recommending
hard-to-support direct modification of brick contents in favor of
in-line mechanisms. Eventually we might even use SELinux or similar to
preclude back-end twiddling altogether.
The one thing that's a bit awkward about both your suggestion and mine
is how bricks are identified. Identifying bricks by their internal
translator names is *totally* wrong, but identifying them by server:port
is barely any better since those relationships can change. Ideally, a
brick would always be identified by a unique ID, with its current
location as an attribute. This includes not just CLI and logs, but also
things like xattr names used by AFR (and DHT if/when some other issues
with how we store layout information are addressed). IMO fixing brick
identification is necessary before we can provide a proper heal/rm function.
