<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Gianluca,</div><div><br></div>if you don't have plan to use mix of 1.8 and 2.0 clients, you can apply small patch, which should be reduce MDS traffic.<div><br></div><div><div>diff --git a/lustre/llite/dcache.c b/lustre/llite/dcache.c </div><div>index 22a929d..b133956 100644 </div><div>--- a/lustre/llite/dcache.c </div><div>+++ b/lustre/llite/dcache.c </div><div>@@ -427,9 +427,6 @@ int ll_revalidate_it(struct dentry *de, int lookup_flags, </div><div> ll_frob_intent(&it, &lookup_it); </div><div> LASSERT(it); </div><div> </div><div>- if (it->it_op == IT_LOOKUP && !(de->d_flags & DCACHE_LUSTRE_INVALID)) </div><div>- GOTO(out_sa, rc = 1); </div><div>- </div><div> ll_prepare_mdc_op_data(&op_data, parent, de->d_inode, </div><div> de->d_name.name, de->d_name.len, 0, NULL); </div><div> </div><div>that patch add more cache on client side, but have some interop issue in mixed env, which need to be fixed on MDS side.</div><div><br></div><div><br></div><div><br></div><div><div>On Nov 19, 2010, at 14:15, Gianluca Tresoldi wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div bgcolor="#ffffff" text="#000000">
Hi everyone,<br>
<br>
I'm testing lustre 2.0 in a pre-production environment and I
encountered some problems.<br>
<br>
My test environment consists of:<br>
1 MDS/MGS (not combined) with 48G of ram and 16 xeon E5520 core<br>
1 OSS with the same characteristics.<br>
1 Client <br>
Both MDS and OSS are connected to an ISCSI shared storage with
different volumes.<br>
<br>
I've also production environment with lustre 1.8.2 and 2 filesystem
served by:<br>
2 MDS/MGS where each server is active for one file system and
passive for other.<br>
2 OSS: Same configuration of MDS.<br>
50 Client that runs apache web-server.<br>
<br>
I've performed a 8 hours stress test in both environment using
apache log's for replicate real traffic, this is the results:<br>
<br>
Lustre 1.8.2<br>
Avg load: on Mds 0,8 on Oss 0,2 and network load on mds (on gigabit
NIC dedicated to lustre traffic) about 50.000 Kb/s.<br>
<br>
Lustre 2.0.0<br>
Avg load: on Mds 2,8 on Oss 0,1 and network load on mds (on gigabit
NIC dedicated to lustre traffic) about 180.000 Kb/s.<br>
<br>
On lustre 2.0 the network traffic is much higher than on Lustre
1.8.2, if we considered that in addition to the stress test, on
Lustre 1.8.2, also production runs, i think there is a problem.<br>
<br>
With TCPDump I saw that when I run multiple "ls -l" on Client
connected to lustre 1.8.2 only some time client send packet to MDS,
with client connected to lustre 2.0 all the time.<br>
<br>
I Think that client 2.0 doesn' t cache files' attr.<br>
<br>
<br>
could someone help me?<br>
Thanks in advice and have a very nice day. ;)<br>
<br>
P.S.<br>
Sorry for my not perfect English.<br>
<br>
<div class="moz-signature">-- <br>
Gianluca Tresoldi<br>
***SysAdmin***<br>
***Demon's Trainer***<br>
Tuttogratis Italia Spa<br>
E-mail: <a class="moz-txt-link-abbreviated" href="mailto:gianluca.tresoldi@tuttogratis.com">gianluca.tresoldi@tuttogratis.com</a><br>
<a class="moz-txt-link-freetext" href="http://www.tuttogratis.it/">http://www.tuttogratis.it</a><br>
Tel Centralino 02-57313101<br>
Tel Diretto 02-57313136<br>
<a href="http://www.gnu.org/"><span><linux40.jpg></span></a>Be
open...<br>
<b>*********** Confidentiality Notice & Disclaimer
*************<br>
This message, together with any attachments, is for the
confidential<br>
and exclusive use of the addressee(s). If you receive it in
error,<br>
please delete the message and its attachments from your system<br>
immediately and notify us by return e-mail.<br>
Do not disclose, copy, circulate or use any information
contained in<br>
this e-mail.<br>
</b>
</div>
</div>
_______________________________________________<br>Lustre-discuss mailing list<br><a href="mailto:Lustre-discuss@lists.lustre.org">Lustre-discuss@lists.lustre.org</a><br>http://lists.lustre.org/mailman/listinfo/lustre-discuss<br></blockquote></div><br></div></body></html>