I know that when free capacity for a brick is less than min-free-disk,
create a link file.
but, when all subvols’ free capacity are less than min-free-disk,
just try to search the best subvol and do fops to the subvol.
I think restriction is needed as option.
so, i suggest that when all subvols’ free capacity are less than min-free-disk,
reject fops for create and mknod (using min-free-disk).
like below codes. (of course, needed to modify the function;
dht_free_disk_available_subvol)
avail_subvol = dht_free_disk_available_subvol (this, subvol,
local);
if (!avail_subvol) {
gf_msg_debug (this->name, 0,
"failed to create %s on %s",
loc->path, subvol->name);
DHT_STACK_UNWIND (mknod, frame, -1, ENOSPC,
NULL, NULL, NULL, NULL, NULL);
goto out;
}
else if (avail_subvol != subvol) {
local->params = dict_ref (params);
local->rdev = rdev;
local->mode = mode;
local->umask = umask;
local->cached_subvol = avail_subvol;
local->hashed_subvol = subvol;
gf_msg_debug (this->name, 0,
"creating %s on %s (link at %s)",
loc->path,
avail_subvol->name, subvol->name);
dht_linkfile_create (frame,
dht_mknod_linkfile_create_cbk,
this, avail_subvol, subvol, loc);
goto out;
}
- 이태화 드림 -
-----------------------------------------
이 태 화
Taehwa Lee
Gluesys Co.,Ltd.
[email protected]
010-3420-6114, 070-8785-6591
-----------------------------------------
> 2017. 7. 13. 오후 3:22, Nithya Balachandran <[email protected]> 작성:
>
>
>
> On 13 July 2017 at 11:46, Pranith Kumar Karampuri <[email protected]
> <mailto:[email protected]>> wrote:
>
>
> On Thu, Jul 13, 2017 at 10:11 AM, Taehwa Lee <[email protected]
> <mailto:[email protected]>> wrote:
> Thank you for response quickly
>
>
> I went through dht_get_du_info before I start developing this.
>
> at that time, I think that this functionality should be independent module.
>
>
> so, I will move this into DHT without new statfs.
>
>
> Can you provide the details of your usecase? I ask because we already have
> dht redirecting creates to other subvols if a particular brick's usage
> crosses a certain value.
>
>
> Let's here from dht folks also what they think about this change before you
> make modifications. I included some of the dht folks to the thread.
>
>
> and then, will suggest it on gerrit !
>
>
> Thank you so much.
>
>
> -----------------------------------------
> Taehwa Lee
> Gluesys Co.,Ltd.
> [email protected] <mailto:[email protected]>
> +82-10-3420-6114, +82-70-8785-6591
> -----------------------------------------
>
>> 2017. 7. 13. 오후 1:06, Pranith Kumar Karampuri <[email protected]
>> <mailto:[email protected]>> 작성:
>>
>> hey,
>> I went through the patch. I see that statfs is always wound for create
>> fop. So number of network operations increase and performance will be less
>> even in normal case. I think similar functionality is in DHT, may be you
>> should take a look at that?
>>
>> Check dht_get_du_info() which is used by dht_mknod(). It keeps refreshing
>> this info every X seconds. I will let DHT guys comment a bit more about
>> this. One more thing to check is if we can have just one implementation that
>> satisfied everyone's requirements. i.e. move out this functionality from DHT
>> to this xlator or, move the functionality of this xlator into DHT.
>>
>>
>> On Thu, Jul 13, 2017 at 8:18 AM, Taehwa Lee <[email protected]
>> <mailto:[email protected]>> wrote:
>> Hi all,
>>
>> I’ve been developing a xlator that create is rejected when used capacity of
>> a volume higher than threshold.
>>
>>
>> the reason why I’m doing is that I got problems when LV is used fully.
>>
>> this patch is in the middle of develop.
>>
>> just I want to know whether my approach is pretty correct to satisfy my
>> requirement.
>>
>> so, when you guys have a little spare time, please review my patch and tell
>> me WHATEVER you’re thinking.
>>
>>
>> and If you guys think that it is useful for glusterfs, I’m gonna do process
>> to merge into glusterfs.
>>
>>
>> thanks in advance
>>
>>
>>
>>
>>
>> -----------------------------------------
>> Taehwa Lee
>> Gluesys Co.,Ltd.
>> [email protected] <mailto:[email protected]>
>> +82-10-3420-6114, +82-70-8785-6591
>> -----------------------------------------
>>
>>
>> _______________________________________________
>> Gluster-devel mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>> <http://lists.gluster.org/mailman/listinfo/gluster-devel>
>>
>>
>>
>> --
>> Pranith
>
>
>
>
> --
> Pranith
>
_______________________________________________
Gluster-devel mailing list
[email protected]
http://lists.gluster.org/mailman/listinfo/gluster-devel
