Submitter : dxm Status : open
Assigned Engineer : dxm Priority : 3
*Modified Date : 09/18/00 *Modified User : dxm
*Modified User Domain : melbourne *Description :
I haven't seen this problem for ages on my 64Mb crash box,
but the problem is still there.
I installed XFS on my home machine last night and was very
happy with its performance (P100, 32Mb RAM, 32Gb disk) until
I tried to cleanly remount my XFS partition and tripped an
ASSERT in xlog_get_bp.
My home machine is very tight on memory, but I don't think
it's an unreasonable machine to try to run XFS on. Unfortunately,
.....
==========================
ADDITIONAL INFORMATION (ADD)
From: daniel moore <dxm@xxxxxxxxxxxxxxxxxxxxxxxx>
Date: Sep 18 2000 03:45:04PM
[pvnews version: 1.71]
==========================
lord@xxxxxxx writes:
=> Ideally we do need a better way for recovery to run without
=> chewing up large chunks of memory. Without looking at the
=> code I bet this is the case where we are asking for a 128K
=> buffer to read log space into. This is actually half the amount
=> which Irix would use at this point. A single buffer is requested
=> which would cover the maximum number of iclogs * the max size of
=> an iclog. On Irix we can have 8 32K byte iclogs, on Linux this
=> was reduced to 4.
Yep find_zeroed is asking for 128k.
=>
=> So what we really need here is a change in the algorithm used
=> in xlog_find_zeroed() so that disk I/O can be done in smaller
=> chunks rather than reading one large chunk and processing it.
Other places in log_recover ask for buffers up to 128k too.
=> An interim fix would be to make the mount fail cleanly.
That bit is easy.
I actually hacked home copy last night so it uses single block reads
and writes instead of using large buffers. This works ok, but
I'm wondering if it would be worth the effort to change the code so
it works with the largest buffer it can get. ie so if it can't get
128k, it tries for 64k and works with that etc...
Would it be worth me checking in a change to make the mount fail
cleanly for beta?
|