This is a heads up to all devs that we have now renamed the glusterd log
file from $INSTALL_PREFIX-etc-glusterfs-glusterd.vol.log to glusterd.log in
mainline [1] to avoid confusions for many gluster users. I've seen users
reverting to emails asking for which log file to look at when asked for
currently all the libgfapi logs defaults to '/dev/stderr' as it was hardcoded
in a call to glfs logging api, in case if debug level is chosen to DEBUG/TRACE
gfapi logs will be huge and fill/overflow the console view.
this patch provides a commandline option to mention log file path which helps
in
As some of you might already have noticed, GlusterD has been notably insecure
ever since it was written. Unlike our I/O path, which does check access
control on each request, anyone who can craft a CLI RPC request and send it to
GlusterD's well known TCP port can do anything that the CLI
Today's meeting didn't go according to the agenda, as we initially had
low attendance. Attendance overall was low as well owing to a holiday
in Bangalore.
The meeting minutes and logs for the meeting are available at the links below,
Minutes:
Hi All,
i am trying to do some gluster testing for my customer.
I am experiencing the same issue as described here:
http://serverfault.com/questions/782602/glusterfs-rebalancing-volume-failed
Except: I have dispersed-distributed volume.
And I only let the fix-layout run for a few hours
On Wed, Jul 6, 2016 at 12:24 AM, Shyam wrote:
> On 07/01/2016 01:45 AM, B.K.Raghuram wrote:
>
>> I have not gone through this implementation nor the new iscsi
>> implementation being worked on for 3.9 but I thought I'd share the
>> design behind a distributed iscsi