[Gluster-devel] create restrictions xlator
Taehwa Lee
alghost.lee at gmail.com
Thu Jul 13 07:39:59 UTC 2017
the issue is same as me almost.
It looks better than my suggestion.
but, It is planned on Gluster 4.0, isn’t it?
Can I follow and develop this issue for 3.10 and master?
I want to know what you need and what I can do
-----------------------------------------
Taehwa Lee
Gluesys Co.,Ltd.
alghost.lee at gmail.com
+82-10-3420-6114, +82-70-8785-6591
-----------------------------------------
> 2017. 7. 13. 오후 4:18, Amar Tumballi <atumball at redhat.com> 작성:
>
> Just by looking at the need, it looked like more of https://github.com/gluster/glusterfs/issues/236 <https://github.com/gluster/glusterfs/issues/236>
>
> Will the above change in posix itself be better?
>
> -Amar
>
> On Thu, Jul 13, 2017 at 12:04 PM, Taehwa Lee <alghost.lee at gmail.com <mailto:alghost.lee at gmail.com>> wrote:
> 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.
> alghost.lee at gmail.com <mailto:alghost.lee at gmail.com>
> 010-3420-6114, 070-8785-6591
> -----------------------------------------
>
>> 2017. 7. 13. 오후 3:22, Nithya Balachandran <nbalacha at redhat.com <mailto:nbalacha at redhat.com>> 작성:
>>
>>
>>
>> On 13 July 2017 at 11:46, Pranith Kumar Karampuri <pkarampu at redhat.com <mailto:pkarampu at redhat.com>> wrote:
>>
>>
>> On Thu, Jul 13, 2017 at 10:11 AM, Taehwa Lee <alghost.lee at gmail.com <mailto:alghost.lee at gmail.com>> 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.
>> alghost.lee at gmail.com <mailto:alghost.lee at gmail.com>
>> +82-10-3420-6114, +82-70-8785-6591
>> -----------------------------------------
>>
>>> 2017. 7. 13. 오후 1:06, Pranith Kumar Karampuri <pkarampu at redhat.com <mailto:pkarampu at redhat.com>> 작성:
>>>
>>> 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 <alghost.lee at gmail.com <mailto:alghost.lee at gmail.com>> 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.
>>> alghost.lee at gmail.com <mailto:alghost.lee at gmail.com>
>>> +82-10-3420-6114, +82-70-8785-6591
>>> -----------------------------------------
>>>
>>>
>>> _______________________________________________
>>> Gluster-devel mailing list
>>> Gluster-devel at gluster.org <mailto:Gluster-devel at gluster.org>
>>> http://lists.gluster.org/mailman/listinfo/gluster-devel <http://lists.gluster.org/mailman/listinfo/gluster-devel>
>>>
>>>
>>>
>>> --
>>> Pranith
>>
>>
>>
>>
>> --
>> Pranith
>>
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org <mailto:Gluster-devel at gluster.org>
> http://lists.gluster.org/mailman/listinfo/gluster-devel <http://lists.gluster.org/mailman/listinfo/gluster-devel>
>
>
>
> --
> Amar Tumballi (amarts)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20170713/1c4016c3/attachment-0001.html>
More information about the Gluster-devel
mailing list