[Gluster-devel] create restrictions xlator

[Amar Tumballi]

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/416db9a6/attachment-0001.html>