Inputs requested on 3.2.0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I heartily second all of these, having had to deal with issues related to all of them.

Stability and better troubleshooting tools are the highest possible priorities for me - even now, I'm not sure I can get my user community to re-engage with using GlusterFS, though I am certainly trying.

-----Original Message-----
From: gluster-users-bounces at gluster.org [mailto:gluster-users-bounces at gluster.org] On Behalf Of Mike Hanby
Sent: Wednesday, May 25, 2011 10:44 AM
To: 'Whit Blauvelt'; paul simpson
Cc: Vidya Sakar; gluster-users at gluster.org
Subject: Re: Inputs requested on 3.2.0

Also, the ability to list out all of the config settings for a volume, including those that are still at default.

> -----Original Message-----
> From: gluster-users-bounces at gluster.org [mailto:gluster-users-
> bounces at gluster.org] On Behalf Of Whit Blauvelt
> Sent: Wednesday, May 25, 2011 7:06 AM
> To: paul simpson
> Cc: Vidya Sakar; gluster-users at gluster.org
> Subject: Re: Inputs requested on 3.2.0
> 
> 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
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
_______________________________________________
Gluster-users mailing list
Gluster-users at gluster.org
http://gluster.org/cgi-bin/mailman/listinfo/gluster-users


DISCLAIMER: 
This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this in error, please immediately notify me and permanently delete the original and any copy of any e-mail and any printout thereof. E-mail transmission cannot be guaranteed to be secure or error-free. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. 
NOTICE REGARDING PRIVACY AND CONFIDENTIALITY Knight Capital Group may, at its discretion, monitor and review the content of all e-mail communications. http://www.knight.com


[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux