Re: filesystem bug?

[Tsuchiya Yoshihiro]

Stephen C. Tweedie wrote:

>>>Following is the failed combination:
>>>Redhat9 with 2.4.20-8 ext2 and ext3
>>>Redhat9 with 2.4.20-19.9 ext2 and ext3
>>>Redhat9 with 2.4.20-24.9 ext2
>>>      
>>>
>>I forgot to mention that I had been testing 2.4.20 from kernel.org 
>>also.... And it failed now!
>>    
>>
>
>This looks more and more like either bad hardware, or a specific device
>driver problem.  What storage is being used here?
>
>  
>
Hi,

Stephen, I don't think it is a hardware problem, since this problem
happens on
several different machines, and it happens both on SCSI disk and
our own iSCSI like device driver. I typically use:

scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
<Adaptec aic7899 Ultra160 SCSI adapter>
aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs

blk: queue c1671674, I/O limit 4095Mb (mask 0xffffffff)
Vendor: SEAGATE Model: ST336753LC Rev: DX03


>It could possibly be a core VFS bug, but the VFS is in general pretty
>reliable under load.  We've had problems under specific edge conditions
>such as races between sync and unmount, but the basic VFS behaviour
>under load generally gets _lots_ of testing, so I'd definitely start by
>looking elsewhere.  
>
>I'd also like to see how your 2.4.23 and 2.6.0-test11 testing is going. 
>That might give some clues, too.  There's a race between clear_inode()
>and read_inode() fixed in those kernels, but that doesn't look relevant
>here; there may be something else changed that's significant, though.
>
>  
>
EXT3 on 2.4.23 and 2.6.0-test11 both failed. I feel when I make the
filesystem
smaller - make the filesystem usage 70% to 80% during the test- ,
the problem happens easyer.

Yoshi
--
Yoshihiro Tsuchiya


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/