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. [email protected] +82-10-3420-6114, +82-70-8785-6591 ----------------------------------------- > 2017. 7. 13. 오후 4:18, Amar Tumballi <[email protected]> 작성: > > 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 <[email protected] > <mailto:[email protected]>> 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. > [email protected] <mailto:[email protected]> > 010-3420-6114, 070-8785-6591 > ----------------------------------------- > >> 2017. 7. 13. 오후 3:22, Nithya Balachandran <[email protected] >> <mailto:[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] <mailto:[email protected]> > http://lists.gluster.org/mailman/listinfo/gluster-devel > <http://lists.gluster.org/mailman/listinfo/gluster-devel> > > > > -- > Amar Tumballi (amarts)
_______________________________________________ Gluster-devel mailing list [email protected] http://lists.gluster.org/mailman/listinfo/gluster-devel
