<div dir="ltr">Thx Andreas.<br><br><div class="gmail_extra">re: block bitmaps - yes that is what I really meant. My experience with filesystems is mainly from CPM/BDOS, where "directory" and block mapping are essentially synonymous.<br>
<br></div><div class="gmail_extra">And now I understand about the timing. Makes sense when you describe it that way.<br><br></div><div class="gmail_extra">My system is ext4, although I doubt that I used "flex_bg" option, since this was first created awhile back. I did try to run e4defrag. It simply said that no defrag was needed.<br>
<br></div><div class="gmail_extra">So, now I'm only left in  need of a work-around. Perhaps a way to have the system load the bitmaps at boot time in the background? It would need to be done in such a way that it would not block any other access to that system. Or, is there a better filesystem format that would not have this problem? (Not a really great solution, since I would need to somehow/somewhere backup my 7.5TB system first.)<br>
<br></div><div class="gmail_extra">It does seem strange that this hasn't become a more serious issue, as typical filesystems are getting bigger now. And I can't imagine a really large network server (10TB+) having to deal with this.<br>
<br></div><div class="gmail_extra">Again, thx for the response.<br><br>ken<br><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Sat, Jan 18, 2014 at 9:09 AM, Andreas Dilger <span dir="ltr"><<a href="mailto:adilger@dilger.ca" target="_blank">adilger@dilger.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Jan 17, 2014, at 9:32, Ken Bass <<a href="mailto:daytooner@gmail.com">daytooner@gmail.com</a>> wrote:<br>

><br>
> 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.<br>

><br>
> 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.<br>
<br>
</div>It isn't actually directory information that is being loaded, but rather the<br>
block bitmaps from each group, and each one needs a seek to read.<br>
This will take up to 7.5 TB / 128 MB/group / 100 seeks/sec = 600s<br>
if the filesystem is nearly full. After this point, the bitmaps are cached<br>
In memory and allocation is faster.<br>
<div class="im"><br>
> 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.<br>

><br>
> 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.<br>
><br>
> 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.<br>

><br>
> 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>You might consider mounting the filesystem as ext4 instead of ext3.<br>
It will do a slightly better job of finding contiguous free space<br>
and avoid loading bitmaps that do not have enough space, but the<br>
physics of seeking to read bitmaps is still the same.<br>
<br>
If you format a new filesystem as ext4 (as opposed to just mounting the<br>
existing filesystem as ext4) you can use a new feature "flex_bg" that<br>
locates the block and inode bitmaps together so that they can be read<br>
without so much seeking. You'd need a spare disk to format and copy<br>
the data over to.<br>
<br>
Using ext4 is also more resistant to fragmentation over time.<br>
<br>
Cheers, Andreas<br>
<div class="im"><br>
> Any suggestions, tips, etc. greatly appreciated.<br>
><br>
> TIA<br>
><br>
> ken<br>
><br>
</div>> _______________________________________________<br>
> Ext3-users mailing list<br>
> <a href="mailto:Ext3-users@redhat.com">Ext3-users@redhat.com</a><br>
> <a href="https://www.redhat.com/mailman/listinfo/ext3-users" target="_blank">https://www.redhat.com/mailman/listinfo/ext3-users</a><br>
</blockquote></div><br></div></div>