[Pvfs2-users] Data corruption?

[Number Cruncher]

The kernel where these errors are reported is 2.6.16-1.2115_FC4smp and
the files were restored using
rsync -avv -B 4194304 /media/pvfs_backup/pvfs2-fs/   /pvfs2-fs/

The "-B" forces a reasonable (4MB) block size, and it's
rsync-2.6.8-1.FC4.1 which just uses read/write VFS calls.

Is there any way of find which file/directory corresponds to a given handle?

Thanks,
Simon


Sam Lang wrote:

>Hi Simon,
>
>I'm not able to reproduce this yet on my machine.  Can you give me more
>details about your setup?  What kernel version are you running on?  When
>you did the restore from XFS, did you just copy everything over using cp?
>
>-sam
>
>Number Cruncher wrote:
>  
>
>>Sam Lang wrote:
>>
>>    
>>
>>>>[E 13:38:09.445405] TROVE:DBPF:Berkeley DB: DB->get: DB_NOTFOUND: No
>>>>matching key/data pair found
>>>>[E 13:38:09.448542] TROVE:DBPF:Berkeley DB: DB->get: DB_NOTFOUND: No
>>>>matching key/data pair found
>>>>[E 13:38:09.470425] TROVE:DBPF:Berkeley DB: DB->get: DB_NOTFOUND: No
>>>>matching key/data pair found
>>>>  
>>>>        
>>>>
>>>This message was being printed for a non-failure case.  Its been removed
>>>for that case in the 1.5.1 release.  It doesn't mean that anything is
>>>wrong with your filesystem.
>>>
>>> 
>>>
>>>      
>>>
>>>>The client kernel also sometimes reports:
>>>>
>>>>pvfs2_file_read: error writing to handle 1840698453, -- returning -2
>>>>  
>>>>        
>>>>
>>>I'm not sure about this one.  Is it always the same handle?
>>>
>>> 
>>>
>>>      
>>>
>>Yes, I think so.
>>
>>    
>>
>>>>And pvfs2-fsck gives:
>>>>....
>>>># looking for dirdata match to 920349294.
>>>># mgmt_get_dirdata returned 920349293.
>>>># looking for dirdata match to 613565917.
>>>># mgmt_get_dirdata returned 613565916.
>>>># looking for dirdata match to 1227132674.
>>>># mgmt_get_dirdata returned 1227132673.
>>>># second pass: finding orphaned sub trees.
>>>>* not removing None 2454203121.
>>>>  
>>>>        
>>>>
>>>The lines beginning with # are ok, this one is a little odd.  Could you
>>>send the whole output from fsck?
>>> 
>>>
>>>      
>>>
>>It's a bit long (50k lines), so I've attached it as .txt.bz2
>>
>>
>>
>>    
>>