<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Sunil,<br><br>&nbsp; Hmm, I thought you meant the cluster size.<br><br>Regards,<br>Luis <br><br>--- On <b>Wed, 1/28/09, Sunil Mushran <i>&lt;sunil.mushran@oracle.com&gt;</i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">From: Sunil Mushran &lt;sunil.mushran@oracle.com&gt;<br>Subject: Re: [Ocfs2-users] ocfs2 hangs during webserver usage<br>To: lfreitas34@yahoo.com<br>Cc: ocfs2-users@oss.oracle.com<br>Date: Wednesday, January 28, 2009, 1:08 AM<br><br><pre>Luis Freitas wrote:<br>&gt;    The extent size would play a role on this also, as Sunil pointed. You<br>could check if the extent size is different on your test environment. The mkfs<br>tool might have defaulted a larger extent size if the total size of the<br>filesystem is larger. (Sunil, correct me on this if I am wrong).<br><br>The extend size
 I was referring to is not related to any ondisk size.<br>It depends on the location the write() is issued to. Say you have a<br>100K sized file and you issue a write() at offset 1G. If the fs supports<br>sparse files, it will allocate (and init) blocks only around the 1G location,<br>leaving a hole in between. A non-sparsefile supporting fs, on the other hand,<br>will need to allocate (and init) the entire space between 100K and 1G.<br><br></pre></blockquote></td></tr></table><br>