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....@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....@gmail.com > 010-3420-6114, 070-8785-6591 > ----------------------------------------- > > 2017. 7. 13. 오후 3:22, Nithya Balachandran <nbala...@redhat.com> 작성: > > > > On 13 July 2017 at 11:46, Pranith Kumar Karampuri <pkara...@redhat.com> > wrote: > >> >> >> On Thu, Jul 13, 2017 at 10:11 AM, Taehwa Lee <alghost....@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....@gmail.com >>> +82-10-3420-6114, +82-70-8785-6591 >>> ----------------------------------------- >>> >>> 2017. 7. 13. 오후 1:06, Pranith Kumar Karampuri <pkara...@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....@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....@gmail.com >>>> +82-10-3420-6114, +82-70-8785-6591 >>>> ----------------------------------------- >>>> >>>> >>>> _______________________________________________ >>>> Gluster-devel mailing list >>>> Gluster-devel@gluster.org >>>> http://lists.gluster.org/mailman/listinfo/gluster-devel >>>> >>> >>> >>> >>> -- >>> Pranith >>> >>> >>> >> >> >> -- >> Pranith >> > > > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://lists.gluster.org/mailman/listinfo/gluster-devel > -- Amar Tumballi (amarts)
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel