Re: PROBLEM: Reiserfs stall 2.6.10-bk7 up through 2.6.12-rc3

[Jan Kara <jack@suse.cz>]

  Hello,

  thanks for your report. It was quite complete so it was not a big
problem to find the bug ;)

> On Fri, 2005-05-06 at 18:13 -0700, George Ronkin wrote:
> > ... one of my machines now stalls
> > attempting to access the reiserfs file system used as that server's
> > spool...  This problem did not occur before 2.6.10-bk7.  That and all subsequent
> > kernels I've tried (Debian 2.6.11, stock 2.6.12-rc3, and 2.6.12-rc3-mm3)
> > cause the problem, consistently and repeatably.
> 	As does 2.6.12-rc4.  The unusual 1K block size I used for this reiserfs
> seems to have exposed the problem; all my other reiserfs use 4K and have
> no problem.  I copied its contents to a new reiserfs I created with 4K
> blocks and the later kernels work fine with the copy.  I also tried
> turning off CONFIG_QUOTA on 2.6.12-rc4 - that worked with the 1K block
> reiserfs as well.  I'm keeping the 4K block copy, since that works with
> QUOTA, and turning QUOTA off affects non-reiserfs fs as well.
> 	Note also:
> 
> - The 1K block fs caused the problem even though no quota mount options
> were set.
> 
> - All my reiserfs are devmapped, so I don't know if the problem occurs
> without it on a physical partition, or whether the symptoms would
> differ.
  Hmm, I think the following is happening: with 1KB blocksize we call
journal_begin() with nblocks larger than the biggest possible size of the
transaction (actually your trace in the previous mail was truncated and
I did not see any such process. It would be nice if you could increase
the size of kernel logging buffer - it's in the kernel config - and acquire
the trace again to confirm my suspicion).
  Quota is quite hungry regarding the number of blocks it requires in
a transaction - in setattr we require 558 blocks - and from your boot
messages I can see that your filesystem has maximum transaction size 256
blocks.
  Chris, I don't quite understand these computations in journal_init() -
why do we divide by the 'ratio' when the block size is smaller than
1024? We always count in the number of blocks regardless the block size,
don't we? Also we should add an assertion into journal_start() to BUG()
if we call it with too big nblocks. I guess I should also revise the
quota code and somehow achieve a less pesimistic estimates on the number
of dirtied blocks.
  I'm sorry but I won't be reading emails for the next two days.
Afterwards I'll work on the fix.

								Honza

-- 
Jan Kara <jack@suse.cz>
SuSE CR Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/