On Nov 14, 2006 13:38 -0600, Eric Sandeen wrote:
> Andreas Dilger wrote:
> > It would make sense to fix ext2 in the same way.
> > I'd suggest bailing out "early" == min(i_size >> blocksize, i_blocks).
> > The i_blocks count is an upper limit, because it includes the overhead of
> > indirect blocks
Andreas Dilger wrote:
> On Nov 14, 2006 09:25 -0600, Eric Sandeen wrote:
>> has an image with a corrupt directory inode - despite having only 4 blocks,
>> it has an extremely large i_size.
>>
>> It seems odd to me that readdir bails out with an error on the first bad
>> page, while lookup keeps
On Nov 14, 2006 09:25 -0600, Eric Sandeen wrote:
> has an image with a corrupt directory inode - despite having only 4 blocks,
> it has an extremely large i_size.
>
> It seems odd to me that readdir bails out with an error on the first bad
> page, while lookup keeps trying. Shouldn't these be
the fsfuzzer has been keeping me busy lately ;-)
http://kernelfun.blogspot.com/2006/11/mokb-09-11-2006-linux-26x-ext2checkpage.html
has an image with a corrupt directory inode - despite having only 4 blocks, it
has an extremely large i_size.
readdir & lookup seem to behave differently when ex
