On Wed, May 25, 2011 at 12:09:47PM +0100, paul simpson wrote: > 2/ better reporting. ie, we should be able to know which files are not > replicated. right now, there's no way knowing how safe any of your data > is. i'd be interested if this is even possible with the very > decentralised way gluster works? I agree with all Paul's points. On this one, something I notice as people report problems with files is that we're asked to run very cryptic shell utilities to check the state of the extended attributes. Why not wrap these in some Python, along with a few of the ways that are suggested to trigger self-heal? You've got a vastly simplified initial setup for Gluster, compared to similar filesystems. But then for maintenance you're basically asking people to do it by hand - with neither comprehensive documentation of how to do that the hard way, nor simplified utilities do it more easily. If it never broke, this would be fine. But filesystems - even more basic and mature ones - break all the time. So assume it's going to break, and make sure the tools to deal with that are readily available and usable by a sysadmin at 4 in the morning, who may not have time to go to this list, or file a bug report and wait for response, before fixing the problem for users. Best, Whit