Very long delay for first write to big filesystem

--===============4399023934227838451==
Content-Type: multipart/alternative; boundary=047d7b6d80b4b0486604f02d17e3

--047d7b6d80b4b0486604f02d17e3
Content-Type: text/plain; charset=ISO-8859-1

I asked about this a while back. It seems that this problem is getting much
worse.

The problem/issue: there is a very long delay when my system does a write
to the filesystem. The delay now is over 5 minutes (yes: minutes). This
only happens on the first write after booting up the system, and only for
large files - 1GB or more. This can be a serious problem since all access
to any hard disk is blocked and will hang until the first write begins
again.

The prevailing thought at the time was this was associated with loading
into memory the directory information looking for free space, which I would
believe now.

The filesystem in question is 7.5TB, with about 4TB used. There are over
250,000 files. I also have another system with 1TB total and 400GB used,
with 65,000 files. This system, the smaller one, is beginning to show
delays as well, although only a few seconds.

This problem seems to involve several factors: the total size of the
system; the current "fragmentation" of that system; and finally the amount
of physical memory available.

As to the last factor, the 7.5TB system has only 2GB of memory (I didn't
think that it would need a lot since it is mostly being used as a file
server). The "fragmentation" factor (I am only guessing here) occurs with
having many files written and deleted over time.

So my questions are: is there a solution or work around for this; and is
this a bug, or perhaps an undesirable feature. If the latter, should this
be reported (somewhere)?

Any suggestions, tips, etc. greatly appreciated.

TIA

ken

--047d7b6d80b4b0486604f02d17e3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div>I asked about this a while back. It se=
ems that this problem is getting much worse.<br><br></div>The problem/issue=
: there is a very long delay when my system does a write to the filesystem.=
 The delay now is over 5 minutes (yes: minutes). This only happens on the f=
irst write after booting up the system, and only for large files - 1GB or m=
ore. This can be a serious problem since all access to any hard disk is blo=
cked and will hang until the first write begins again.<br>
<br></div>The prevailing thought at the time was this was associated with l=
oading into memory the directory information looking for free space, which =
I would believe now.<br><br></div>The filesystem in question is 7.5TB, with=
 about 4TB used. There are over 250,000 files. I also have another system w=
ith 1TB total and 400GB used, with 65,000 files. This system, the smaller o=
ne, is beginning to show delays as well, although only a few seconds.<br>
<br></div><div>This problem seems to involve several factors: the total siz=
e of the system; the current &quot;fragmentation&quot; of that system; and =
finally the amount of physical memory available.<br><br></div><div>As to th=
e last factor, the 7.5TB system has only 2GB of memory (I didn&#39;t think =
that it would need a lot since it is mostly being used as a file server). T=
he &quot;fragmentation&quot; factor (I am only guessing here) occurs with h=
aving many files written and deleted over time.<br>
<br></div><div>So my questions are: is there a solution or work around for =
this; and is this a bug, or perhaps an undesirable feature. If the latter, =
should this be reported (somewhere)?<br><br></div><div>Any suggestions, tip=
s, etc. greatly appreciated.<br>
<br></div><div>TIA<br><br>ken<br><br></div></div>

--047d7b6d80b4b0486604f02d17e3--


--===============4399023934227838451==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ext3-users mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/ext3-users
--===============4399023934227838451==--