Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+Prevent\s+lookup\s+from\s+finding\s+bad\s+buffers\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+Prevent\s+lookup\s+from\s+finding\s+bad\s+buffers\s*$/: 4 ]

Total 4 documents matching your query.

1. [PATCH] Prevent lookup from finding bad buffers (score: 1): Author: Lachlan McIlroy <lachlan@xxxxxxx>; Date: Tue, 10 Feb 2009 13:48:25 +1100; There's a bug in _xfs_buf_find() that will cause it to return buffers that failed to be initialised. If a thread has a buffer locked and is waiting for I/O to initialise it and another thread wants t; /archives/xfs/2009-02/msg00177.html (9,970 bytes)
2. Re: [PATCH] Prevent lookup from finding bad buffers (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Sun, 15 Feb 2009 15:12:00 -0500; Is there a testcase for this?; /archives/xfs/2009-02/msg00312.html (7,344 bytes)
3. Re: [PATCH] Prevent lookup from finding bad buffers (score: 1): Author: Eric Sandeen <sandeen@xxxxxxxxxxx>; Date: Wed, 25 Nov 2009 14:26:19 -0600; I managed to come up with a sorta-kinda testcase for this. Fragmented freespace, many files in a dir, on raid5; simply doing drop caches / ls in a loop triggered it. I guess raid5 is bad in this resp; /archives/xfs/2009-11/msg00215.html (10,096 bytes)
4. Re: [PATCH] Prevent lookup from finding bad buffers (score: 1): Author: Eric Sandeen <sandeen@xxxxxxxxxxx>; Date: Wed, 25 Nov 2009 16:29:09 -0600; Ok, so that was shoot-from-the-hip, and actually it was tested on an older kernel; upstream didn't demonstrate the problem, thanks to: [PATCH] md: return a non-zero error to bi_end_io as appropriate; /archives/xfs/2009-11/msg00223.html (11,531 bytes)

Current List: 1 - 4
Page: [1]