On 13 July 2017 at 11:46, Pranith Kumar Karampuri <[email protected]> wrote:
> > > On Thu, Jul 13, 2017 at 10:11 AM, Taehwa Lee <[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] >> +82-10-3420-6114, +82-70-8785-6591 >> ----------------------------------------- >> >> 2017. 7. 13. 오후 1:06, Pranith Kumar Karampuri <[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]> >> 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] >>> +82-10-3420-6114, +82-70-8785-6591 >>> ----------------------------------------- >>> >>> >>> _______________________________________________ >>> Gluster-devel mailing list >>> [email protected] >>> http://lists.gluster.org/mailman/listinfo/gluster-devel >>> >> >> >> >> -- >> Pranith >> >> >> > > > -- > Pranith >
_______________________________________________ Gluster-devel mailing list [email protected] http://lists.gluster.org/mailman/listinfo/gluster-devel
