[Gluster-devel] create restrictions xlator
Mohit Agrawal
moagrawa at redhat.com
Thu Jul 13 08:09:58 UTC 2017
Yes, we will fix it before 4.0 (3.12).
On Thu, Jul 13, 2017 at 1:09 PM, Taehwa Lee <alghost.lee at gmail.com> wrote:
> 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
>
> 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>
> 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
>> 010-3420-6114, 070-8785-6591
>> -----------------------------------------
>>
>> 2017. 7. 13. 오후 3:22, Nithya Balachandran <nbalacha at redhat.com> 작성:
>>
>>
>>
>> On 13 July 2017 at 11:46, Pranith Kumar Karampuri <pkarampu at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Thu, Jul 13, 2017 at 10:11 AM, Taehwa Lee <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
>>>> +82-10-3420-6114, +82-70-8785-6591
>>>> -----------------------------------------
>>>>
>>>> 2017. 7. 13. 오후 1:06, Pranith Kumar Karampuri <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>
>>>> 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
>>>>> +82-10-3420-6114, +82-70-8785-6591
>>>>> -----------------------------------------
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Gluster-devel mailing list
>>>>> Gluster-devel at gluster.org
>>>>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Pranith
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Pranith
>>>
>>
>>
>>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> 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/25d6e877/attachment.html>
More information about the Gluster-devel
mailing list