[Gluster-users] Bricks filling up

[John Walker]

Please submit the patch while we're in the pre-3.3.2 cycle. The worst that can happen is that the devs write their own.

-JM


Ling Ho <ling at slac.stanford.edu> wrote:

I fixed it  but then saw it in 3.4.0alpha (which I originally thought 
3.3.1). So I figured the official patch is coming, so never bothered to 
report.


On 04/16/2013 03:00 PM, Joe Julian wrote:
> You found a bug. Patched it. And never reported, nor contributed that
> patch??? Grrr... :P
>
> On 04/16/2013 02:58 PM, Ling Ho wrote:
>> No this is our in-house patch. A similar fix is still not in 3.3.2qa
>> but it's in 3.4.0alpha. I couldn't find any bug reported, if any.
>> ...
>> ling
>>
>> On 04/16/2013 02:15 PM, Thomas Wakefield wrote:
>>> Do you have the bug # for this patch?
>>>
>>> On Apr 16, 2013, at 3:48 PM, Ling Ho <ling at slac.stanford.edu> wrote:
>>>
>>>> Maybe I was wrong. I just did a diff and looks like the fix is not
>>>> in 3.3.1. This is the patch I applied to my 3.3.0 build. I didn't
>>>> fix the the check for inodes though. If you look at the code, max is
>>>> defined as 0.
>>>>
>>>> --- glusterfs-3.3.0.orig/xlators/cluster/dht/src/dht-diskusage.c
>>>> 2012-05-30 10:53:24.000000000 -0700
>>>> +++ glusterfs-3.3.0-slac/xlators/cluster/dht/src/dht-diskusage.c
>>>> 2013-03-20 02:25:53.761415662 -0700
>>>> @@ -263,14 +263,14 @@
>>>>          {
>>>>                  for (i = 0; i < conf->subvolume_cnt; i++) {
>>>>                          if (conf->disk_unit == 'p') {
>>>> -                               if ((conf->du_stats[i].avail_percent
>>>>> max)
>>>> +                               if ((conf->du_stats[i].avail_percent
>>>>> conf->min_free_disk)
>>>>                                      &&
>>>> (conf->du_stats[i].avail_inodes > max_inodes)) {
>>>>                                          max =
>>>> conf->du_stats[i].avail_percent;
>>>>                                          max_inodes =
>>>> conf->du_stats[i].avail_inodes;
>>>>                                          avail_subvol =
>>>> conf->subvolumes[i];
>>>>                                  }
>>>>                          } else {
>>>> -                               if ((conf->du_stats[i].avail_space >
>>>> max)
>>>> +                               if ((conf->du_stats[i].avail_space >
>>>> conf->min_free_disk)
>>>>                                      &&
>>>> (conf->du_stats[i].avail_inodes > max_inodes)) {
>>>>                                          max =
>>>> conf->du_stats[i].avail_space;
>>>>                                          max_inodes =
>>>> conf->du_stats[i].avail_inodes;
>>>>
>>>>
>>>> ...
>>>> ling
>>>>
>>>>
>>>> On 04/16/2013 12:38 PM, Thomas Wakefield wrote:
>>>>> Running 3.3.1 on everything, client and servers :(
>>>>>
>>>>> Thomas Wakefield
>>>>> Sr Sys Admin @ COLA
>>>>> 301-902-1268
>>>>>
>>>>>
>>>>>
>>>>> On Apr 16, 2013, at 3:23 PM, Ling Ho <ling at slac.stanford.edu> wrote:
>>>>>
>>>>>> On 04/15/2013 06:35 PM, Thomas Wakefield wrote:
>>>>>>> Help-
>>>>>>>
>>>>>>> I have multiple gluster filesystems, all with the setting:
>>>>>>> cluster.min-free-disk: 500GB.  My understanding is that this
>>>>>>> setting should stop new writes to a brick with less than 500GB of
>>>>>>> free space.  But that existing files might expand, which is why I
>>>>>>> went with a high number like 500GB.  But I am still getting full
>>>>>>> bricks, frequently it's the first brick in the cluster that
>>>>>>> suddenly fills up.
>>>>>>>
>>>>>>> Can someone tell me how gluster chooses where to write a file.
>>>>>>> And why the min-free-disk is being ignored.
>>>>>>>
>>>>>>> Running 3.3.1 currently on all servers.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> -Tom
>>>>>>> _______________________________________________
>>>>>>> Gluster-users mailing list
>>>>>>> Gluster-users at gluster.org
>>>>>>> http://supercolony.gluster.org/mailman/listinfo/gluster-users
>>>>>> Make sure you are running 3.3.1 also on all the clients also. It
>>>>>> is determined by the clients. I noticed there is a fix there is in
>>>>>> 3.3.1 which is not in 3.3.0. In 3.3.0, it will try writing to the
>>>>>> next brick which is the 1st brick, but only check if it is not
>>>>>> 100% (completely) free. If it has 1 byte left, it will start
>>>>>> writing to it, and that's why the 1st brick will get filled up.
>>>>>>
>>>>>> ...
>>>>>> ling
>>>>>> _______________________________________________
>>>>>> Gluster-users mailing list
>>>>>> Gluster-users at gluster.org
>>>>>> http://supercolony.gluster.org/mailman/listinfo/gluster-users
>> _______________________________________________
>> Gluster-users mailing list
>> Gluster-users at gluster.org
>> http://supercolony.gluster.org/mailman/listinfo/gluster-users

_______________________________________________
Gluster-users mailing list
Gluster-users at gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users