On 09/19/2013 02:04 AM, [email protected] wrote:
Thanks for your replies.
My first question is: can I safely issue a "commit" when the volume does
not seem to have drained?
Hi James,
You should be okay in issuing a commit to update the volume information
since the rebalance status command show completed (albeit with failures
for some files). Even if the volume information does get messed up in
the process, it would at least not affect the data that is present in
the back end bricks.
Thanks,
Ravi
One of the other arrays failed completely near the end of the draining, so
I'm guaranteed some data loss in any event; I just don't want to put the
system in an unstable state.
I have questions about that too, but I'll save those for another message.
Thanks,
James Bellinger
On 09/17/2013 03:26 AM, [email protected] wrote:
I inherited a system with a wide mix of array sizes (no replication) in
3.2.2, and wanted to drain data from a failing array.
I upgraded to 3.3.2, and began a
gluster volume remove-brick scratch "gfs-node01:/sda" start
After some time I got this:
gluster volume remove-brick scratch "gfs-node01:/sda" status
Node Rebalanced-files size scanned failures
status
--------- ----------- ----------- ----------- -----------
------------
localhost 0 0Bytes 0 0
not started
gfs-node06 0 0Bytes 0 0
not started
gfs-node03 0 0Bytes 0 0
not started
gfs-node05 0 0Bytes 0 0
not started
gfs-node01 2257394624 2.8TB 5161640 208878
completed
Two things jump instantly to mind:
1) The number of failures is rather large
Can you see the rebalance logs (/var/log/scratch-rebalance.log) to
figure out what the error messages are?
2) A _different_ disk seems to have been _partially_ drained.
/dev/sda 2.8T 2.7T 12G 100% /sda
/dev/sdb 2.8T 769G 2.0T 28% /sdb
/dev/sdc 2.8T 2.1T 698G 75% /sdc
/dev/sdd 2.8T 2.2T 589G 79% /sdd
I know this sounds silly, but just to be sure, is /dev/sda actually
mounted on "gfs-node01:sda"?
If yes,the files that _were_ successfully rebalanced should have been
moved from gfs-node01:sda to one of the other bricks. Is that the case?
When I mount the system it is read-only (another problem I want to fix
Again, the mount logs could shed some information ..
(btw a successful rebalance start/status sequence should be followed by
the rebalance 'commit' command to ensure the volume information gets
updated)
ASAP) so I'm pretty sure the failures aren't due to users changing the
system underneath me.
Thanks for any pointers.
James Bellinger
_______________________________________________
Gluster-users mailing list
[email protected]
http://supercolony.gluster.org/mailman/listinfo/gluster-users
_______________________________________________
Gluster-users mailing list
[email protected]
http://supercolony.gluster.org/mailman/listinfo/gluster-users
_______________________________________________
Gluster-users mailing list
[email protected]
http://supercolony.gluster.org/mailman/listinfo/gluster-users
