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 <[email protected]> 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 <[email protected]> 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
[email protected]
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
[email protected]
http://supercolony.gluster.org/mailman/listinfo/gluster-users

_______________________________________________
Gluster-users mailing list
[email protected]
http://supercolony.gluster.org/mailman/listinfo/gluster-users

Reply via email to