<div>Alex,<br> </div>
<div>We are working on checking the lustre scalability so that we can uptake it in our production infrastructure. Below are the details of our setup, tests conducted and the issues faced till now, <br><strong>Setup details :<br>
--------------------<br></strong><br>Hardware Used - HP DL360 <br>MDT/MGS - 1 <br>OST - 13 (13 HP DL360 servers used, 1 OSS = 1 OST, 700gb x 13 )<br><br><strong>Issue1<br>---------<br>Test Environment: <br></strong><br>Operating System - Redhat EL4 Update 7 ,x86_64<br>
Lustre Version - <a href="http://1.6.5.1">1.6.5.1</a> <br>Lustre Kernel - kernel-lustre-smp-2.6.9-67.0.7.EL_lustre.1.6.5.1.x86_64<br>Lustre Client - Xen Virtual Machines with 2.6.9-78.0.0.0.1.ELxenU kernel( patchless ) <br>
<br><strong>Test Conducted:</strong> Performed heavy read/write ops from 190 lustre clients. Each client tries to read & write 14000 files parallely. <br><br><strong>Errors noticed :</strong> Multiple cliens evicted while writting hugh number of files.Lustre mount is not accessible in the evicted clients. We need to umount and mount to make the lustre accessible in the affected clients. <br>
<br><strong>server side errors noticed <br></strong>-----------------------------------------<br>Nov 26 01:03:48 kernel: LustreError: 29774:0:(handler.c:1515:mds_handle()) operation 41 on unconnected MDS from 12345-[CLIENT IP HERE]@tcp<br>
Nov 26 01:07:46 kernel: Lustre: farmres-MDT0000: haven't heard from client 2379a0f4-f298-9c78-fce6-3d8db74f912b (at [CLIENT IP HERE]@tcp) in 227 seconds. I think it's dead, and I am evicting it.<br>Nov 26 01:43:58 kernel: Lustre: MGS: haven't heard from client 0c239c47-e1f7-47de-0b43-19d5819081e1 (at [CLIENT IP HERE]@tcp) in 227 seconds. I think it's dead, and I am evicting it.<br>
Nov 26 01:54:37 kernel: LustreError: 29766:0:(handler.c:1515:mds_handle()) operation 101 on unconnected MDS from 12345-[CLIENT IP HERE]@tcp<br>Nov 26 02:09:49 kernel: LustreError: 29760:0:(ldlm_lib.c:1536:target_send_reply_msg()) @@@ processing error (-107) <a href="mailto:req@000001080ba29400">req@000001080ba29400</a> x260230/t0 o101-><?>@<?>:0/0 lens 440/0 e 0 to 0 dl 1227665489 ref 1 fl Interpret:/0/0 rc -107/0<br>
Nov 27 01:06:07 kernel: LustreError: 30478:0:(mgs_handler.c:538:mgs_handle()) lustre_mgs: operation 101 on unconnected MGS<br>Nov 27 02:21:39 kernel: Lustre: 18420:0:(ldlm_lib.c:525:target_handle_reconnect()) farmres-MDT0000: 180cf598-1e43-3ea4-6cf6-0ee40e5a2d5e reconnecting<br>
Nov 27 02:22:16 kernel: Lustre: Request x2282604 sent from farmres-MDT0000 to NID [CLIENT IP HERE]@tcp 6s ago has timed out (limit 6s).<br>Nov 27 02:22:16 kernel: LustreError: 138-a: farmres-MDT0000: A client on nid [CLIENT IP HERE]@tcp was evicted due to a lock blocking callback to [CLIENT IP HERE]@tcp timed out: rc -107<br>
Nov 27 08:58:46 kernel: LustreError: 29755:0:(upcall_cache.c:325:upcall_cache_get_entry()) acquire timeout exceeded for key 0<br>Nov 27 08:59:11 kernel: LustreError: 18473:0:(upcall_cache.c:325:upcall_cache_get_entry()) acquire timeout exceeded for key 0<br>
Nov 27 13:23:25 kernel: Lustre: 29752:0:(ldlm_lib.c:525:target_handle_reconnect()) farmres-MDT0000: 3d5efff1-1652-6669-94de-c93ee73a4bc7 reconnecting<br>Nov 27 02:17:16 kernel: nfs_statfs: statfs error = 116<br>------------------------<br>
<br><strong>client errors</strong> <br>------------------------<br><br>cp: cannot open `/master/jdk16/sample/jnlp/webpad/src/version1/ClipboardHandler.java' for reading: Input/output error<br>cp: cannot stat `/master/jdk16/sample/jnlp/webpad/src/version1/CopyAction.java': Cannot send after transport endpoint shutdown<br>
cp: cannot stat `/master/jdk16/sample/jnlp/webpad/src/version1/CutAction.java': Cannot send after transport endpoint shutdown<br>cp: cannot stat `/master/jdk16/sample/jnlp/webpad/src/version1/ExitAction.java': Cannot send after transport endpoint shutdown<br>
cp: cannot stat `/master/jdk16/sample/jnlp/webpad/src/version1/FileHandler.java': Cannot send after transport endpoint shutdown<br>cp: cannot stat `/master/jdk16/sample/jnlp/webpad/src/version1/HelpAction.java': Cannot send after transport endpoint shutdown<br>
cp: cannot stat `/master/jdk16/sample/jnlp/webpad/src/version1/HelpHandler.java': Cannot send after transport endpoint shutdown<br>cp: cannot stat `/master/jdk16/sample/jnlp/webpad/src/version1/JLFAbstractAction.java': Cannot send after transport endpoint shutdown<br>
-------------------------<br><br>Lustre supports Xen kernel 2.6.9-78.0.0.0.1.ELxenU as patchless ? <br><br><br><strong>Issue2 - Tested using Lustre 1.6.6 to see client evicting issue <br>----------------------------------------------------------------------------------------------<br>
<br>Test Environment:</strong> <br><br>Operating System - Redhat EL4 Update 7 ,x86_64<br>Lustre Version - 1.6.6<br>Lustre Kernel - kernel-lustre-smp-2.6.9-67.0.22.EL_lustre.1.6.6.x86_64<br>Lustre Client - Xen Virtual Machines with 2.6.9-78.0.0.0.1.ELxenU kernel( patchless ) <br>
<br><br><strong>Test Conducted:</strong> Performed heavy read/write ops from 190 lustre clients. Each client tries to read & write 14000 files parallely. <br><br>Errors noticed : Same eviction issue noticed in 1.6.6 kernel too.But evited clients got reconnected and lustre file system was accessible without need to umount & mount.The write operation going on in evicted clients was terminated. <br>
<br><strong>Errors - same as Issue1</strong> <br><br><br><strong>Issue3 - Tried accessing lustre via NFS since the eviction issue was noticed only in patchless clients. <br>--------------------------------------------------------------------------------------------------------------------------------------------------------------<br>
</strong><br><strong>Test Environment: <br></strong><br>Operating System - Redhat EL4 Update 7 ,x86_64<br>Lustre Version - 1.6.6<br>Lustre Kernel - kernel-lustre-smp-2.6.9-67.0.22.EL_lustre.1.6.6.x86_64<br>Lustre Client - Xen Virtual Machines with 2.6.9-78.0.0.0.1.ELxenU kernel(nfs clients) <br>
<br>All 13 OST's acts as lustre clients and nfs server exporting Lustrefs via NFS <br><br><strong>NFS options</strong> - *(rw,no_root_squash,async) - settled for this nfs option finally because of the following problem faced in othere nfs options <br>
<br>*(rw) -- Seen IO errors in clients( nfs terminate -61 ) , this issue was fixed by adding "no_root_squash" <br>*(rw,no_root_squash,sync) -- When using sync , mdt was overloaded and write takes long time. <br>
<br><br><strong>Test Conducted:</strong> Performed heavy read/write ops from 190 nfs clients. Each client tries to read & write 14000 files parallely. <br><br><strong>Errors noticed:</strong> <br><br>Lustre was able to withstand the read & write operations but we have seen IO errors while deleting large number of files. But the file system is accessible on OST(nfs server), and no logs seen related to this issue in nfsserver and client. <br>
We understand from some threads the this IO issue is fixed in EL5 kernel so we moved to EL5 for all mdt & ost <br><br><strong>Issue4)</strong> <br><br><strong>Test Environment: <br></strong><br>Operating System - Redhat EL5 Update 2 ,x86_64<br>
Lustre Version - <a href="http://1.6.5.1">1.6.5.1</a> <br>Lustre Kernel - 2.6.18-53.1.14.el5_lustre.1.6.5.1smp <br>Lustre Client - Xen Virtual Machines with 2.6.9-78.0.0.0.1.ELxenU kernel(nfs clients) <br>All OST's acts as lustre clients and nfs server exporting Lustrefs via NFS <br>
<br><strong>Test Conducted:</strong> Performed heavy read/write ops from 190 nfs clients. Each client tries to read & write 14000 files parallely. <br><br><strong>Errors <br></strong><br>We still see IO errors on the clients while deleting large number of files intermittently.But the file system is accessible on OST(nfs server), and no logs seen related to this issue in nfsserver and client. <br>
Also noticed that mdt is more loaded than EL4 kernel with same hardware(load average consistenly above 20 while writting large number of small files) <br><br>Additionally Iscsi modules not working in EL5 lustre kernel. (We could not use ISCSI Volumes for MDT Failover)</div>

<div>( iscsistart: Missing or Invalid version from /sys/module/scsi_transport_iscsi/version. Make sure a up to date scsi_transport_iscsi module is loaded and a up todate version of iscsid is running. Exiting..)<br> </div>

<div> </div>
<div>Thanks,</div>
<div>Anil<br><br><br> </div>
<div class="gmail_quote">On Tue, Dec 2, 2008 at 8:42 PM, Alex Lyashkov <span dir="ltr"><<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:Alexey.Lyashkov@sun.com" target="_blank">Alexey.Lyashkov@sun.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
<div>On Tue, 2008-12-02 at 10:40 +0530, anil kumar wrote:<br>> Hi All,<br>><br>> We have noticed few issues related to patchless client being evicted &<br>> it does not happen while we use Lustre kernel.<br>
 </div>what kernel version user for patchless client ? RHEL4 or something<br>else ?<br>
<div><br>>  As an alternative we exported Lustre filesystem using NFS but have<br>> intermittent issues with NFS with "Input/output error" for few folders<br>> & it recovers on it own.<br> </div>can you post more info about it? console logs, cut<br>
from /var/log/messages from affected client, lustre log?<br>
<div><br>><br>> We are using RHEL 4 x86_64 with lustre 1.6.6;<br>> I have exported as ; "/lin_results *(rw,no_root_squash,async)"   Note:<br>> if I don't use no_root_squash i get consistent IO error while<br>
> executing "ls"<br>><br>> Please let us know if any one know the workaround or fix for this.<br>><br>> Thanks,<br>> Anil<br>><br> </div>> _______________________________________________<br>
> Lustre-discuss mailing list<br>> <a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:Lustre-discuss@lists.lustre.org" target="_blank">Lustre-discuss@lists.lustre.org</a><br>> <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://lists.lustre.org/mailman/listinfo/lustre-discuss" target="_blank">http://lists.lustre.org/mailman/listinfo/lustre-discuss</a><br>
<br></blockquote></div><br>