filesystem bug?

Hi Stephen,

I tried with /bin/zsh, and it seems you are right. The script is working fine for about 2 hours.

So I will try to find out about EIO(inode corruption) problem next.

Thank you so much,

Yoshi

--
Yoshihiro Tsuchiya

Hi,

Thank you for checking.

OK. Under exactly what circumstances have you seen this in the past, as opposed to the other problem? I have not been able to reproduce this one so far.

Cheers,
Stephen

Hello,

The combinations of kernel versions and filesystem types are:
2.4.20-8 ext2
2.4.20-19.9 ext2, ext3
2.4.20-24.9 ext2
2.4.20-28.9 ext2

I do the test with mozilla-1.3.tar.gz and 6 processes in the script, it happens with ext2 within a few hours.

I haven't seen the problem on 2.4.20,23 and 24.

So now I am testing followings:
2.4.24-pre2 ext2 (mozilla-1.3.tar.gz)
2.4.24 ext2 (nvi-1.79.tar.gz)
2.4.20 ext3 (mozilla-1.3.tar.gz)
2.4.23 ext3 (mozilla-1.3.tar.gz)
2.4.24 ext3 (mozilla-1.3.tar.gz)
2.4.20-28.9 ext3 (mozilla-1.3.tar.gz)

Other than 2.4.20-28.9, since they have been running for three days, they seems nice at this point.

What exactly is the race condition between read_inode() and clear_inode() you have
mentioned?

Thanks,
Yoshi

--
Yoshihiro Tsuchiya

Hi,

This one:

http://linux.bkbits.net:8080/linux-2.4/[email protected]

Cheers,
Stephen

Thank you. I think this one does not explain all of my problem.
1. the corrupted inode was still in the parent directory. It is strange because unlink removes the directory entry first and then iput deletes the inode.

2. some time, i_nlink was 0 and i_dtime was set which is I think somewhat related with this patch, but the other time, part of a inode block was cleaned with 0, which I do not understand how at all.

Thank you,
Yoshi

--
Yoshihiro Tsuchiya

Hi,

Yep. I'd really need to see exactly which kernel versions these specific problems reproduce on to take this much further, though. I'll be travelling for the next week and a half, but I'll look for more results once I'm back from that.

Thanks,
Stephen