<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On Monday 02 June 2014 11:06 AM,
Raghavendra G wrote:<br>
</div>
<blockquote
cite="mid:CADRNtgTTvQTThQ+SKU9srydp2Bv9nudD-UHnX+1FRcDC37mCZQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, May 30, 2014 at 2:24 PM,
Raghavendra Bhat <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:rabhat@redhat.com"
target="_blank">rabhat@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi,<br>
<br>
Currently the lru-limit of the inode table in brick
processes is 16384. There is a option to configure it to
some other value. The protocol/server uses inode_lru_limit
variable present in its private structure while creating
the inode table (whose default value is 16384). When the
option is reconfigured via volume set option the
protocol/server's inode_lru_limit variable present in its
private structure is changed. But the actual size of the
inode table still remains same as old one. Only when the
brick is restarted the newly set value comes into picture.
Is it ok? Should we change the inode table's lru_limit
variable also as part of reconfigure? If so, then probably
we might have to remove the extra inodes present in the
lru list by calling inode_table_prune.<br>
</blockquote>
<div><br>
</div>
<div>Yes, I think we should change the inode table's lru
limit too and call inode_table_prune. From what I know, I
don't think this change would cause any problems.<br>
<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
But as of now the inode table is bound to bound_xl which is
associated with the client_t object for the client being connected.
As part of fops we can get the bound_xl (thus the inode table) from
the rpc request (req->trans->xl_private). But in reconfigure
we get just the xlator pointer of protocol/server and dict
containing new options.<br>
<br>
So what I am planning is this. If the xprt_list (transport list
corresponding to the clients mounted) is empty, then just set the
private structure's variable for lru limit (which will be used to
create the inode table when a client mounts). If xprt_list of
protocol/server's private structure is not empty, then get one of
the transports from that list and get the client_t object
corresponding to the transport, from which bould_xl is obtained (all
the client_t objects share the same inode table) . Then from
bound_xl pointer to inode table is got and its variable for lru
limit is also set to the value specified via cli and
inode_table_prune is called to purge the extra inodes. <br>
<br>
Does it sound OK?<br>
<br>
Regards,<br>
Raghavendra Bhat<br>
<br>
Regards,<br>
Raghavendra Bhat<br>
<blockquote
cite="mid:CADRNtgTTvQTThQ+SKU9srydp2Bv9nudD-UHnX+1FRcDC37mCZQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<br>
Please provide feedback<br>
<br>
<br>
Regards,<br>
Raghavendra Bhat<br>
_______________________________________________<br>
Gluster-devel mailing list<br>
<a moz-do-not-send="true"
href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
<a moz-do-not-send="true"
href="http://supercolony.gluster.org/mailman/listinfo/gluster-devel"
target="_blank">http://supercolony.gluster.org/mailman/listinfo/gluster-devel</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Raghavendra G<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Gluster-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a>
<a class="moz-txt-link-freetext" href="http://supercolony.gluster.org/mailman/listinfo/gluster-devel">http://supercolony.gluster.org/mailman/listinfo/gluster-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>