[Ocfs2-users] ocfs2_delete_inode kernel bug

[Sunil Mushran]

On 10/26/2010 10:39 AM, Andre Nathan wrote:
> On Tue, 2010-10-26 at 10:14 -0700, Sunil Mushran wrote:
>> So the backup server is not part of the cluster but yet reading the
>> same block device. As long as it is only reading, it should not affect
>> the two nodes, but I will not trust the backup.
>>
>> The error mentions the inode#. Has it changed?
> Hmm, interesting. I went through the logs and the -17 error happens
> multiple times, but only three inodes are mentioned. Here are the
> counts:
>
>        2 ERROR: Inode 16660075
>       42 ERROR: Inode 16666654
>       46 ERROR: Inode 8528370
>
> I checked the logs I had submitted previously and also only four inode
> numbers show up, but they're different than the ones in this log.
>
>       53 ERROR: Inode 16597043
>       53 ERROR: Inode 16597837
>        6 ERROR: Inode 16656380
>      198 ERROR: Inode 16664401
>
>> Also, is this the mainline kernel?
> No, it's Ubuntu 10.10's kernel.

That means the fsck fixed the older orphaned inodes. That it is
happening with 10.10 is troubling. Are you sure all nodes are on 10.10?

Also, do the errors match the ones in this bz.
http://oss.oracle.com/bugzilla/show_bug.cgi?id=1215

If so, file a new bz. Mention #1215. But don't reopen the older one.
One problem is that 10.10 ships an older ocfs2-tools. debugfs.ocfs2
1.4.4 prints orphaned_slot in the inode. So we cannot gather info
easily.

One solution is for you to attach the raw blocks of the 4 inodes.

For inode#16664401, the command would be:
# dd if=/dev/sdX of=/tmp/blk16664401 bs=4K skip=16664401 count=1
Attach /tmp/blk16664401.

Sunil