Hi, We have encountered another funny with ext3 on 2.4. Like the kernel NFS server, we have a routine in InterMezzo that does something like looking up an inode by inode number. (compare intermezzo's presto_ilookup or knfsd's nfsfh_iget) Effectively both of these routines do ilookup() { inode = iget(sb, ino) if (inode->i_nlink==0) iput(inode); .... } We find that this oopses if the file is recently deleted: echo foo > file rm file "ilookup file" oopses. We suspect that iget gets the inode _without_ hitting ext3_read_inode, ie. it is still in the hash lists. What happens is what we re-enter the ext3_delete_inode path, and something goes wrong when it hits the ext3_orphan_del routine. I think that something is awry, because I would have hoped that after the unlink has run, the inode would not go through another round of ext3_delete_inode. It would be best if ext3_read_inode __was__ called and returned a bad inode, which is more or less what is promised in the comment above the routine. Do we know what is going on here? - Peter -