[Pvfs2-users] Data corruption?

[Number Cruncher]

At the moment the only use for this is surely the failure case 
mentioned, so I guess I can just walk the tree and inspect pvfs2-stat 
output for the handle in question. I.e. don't want to cause loads of 
work for what is essentially only relevant to a (hopefully improbable) 
error condition.

If I understood the docs correctly the handles are unique to a 
particular file/directory or link?


Sam Lang wrote:

>
> On Jul 13, 2006, at 9:50 AM, Rob Ross wrote:
>
>> The problem with storing things like parent directory handle in a  
>> given directory/metafile is that you have to change them all in the  
>> event of a rename. Gets nasty.
>
>
> What about a level of indirection, where the dir handle is added as a  
> keyval to the dirdata handle, and each of the entries in the  
> directory store the dirdata handle, which doesn't change on a rename.
>
> -sam
>
>>
>> Rob
>>
>> Murali Vilayannur wrote:
>>
>>> Hi Simon,
>>>
>>>> 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.
>>>
>>> Hmm.. I will also try and see if we can reproduce this error on our
>>> setup..
>>>
>>>> Is there any way of find which file/directory corresponds to a  
>>>> given handle?
>>>
>>> For a given handle, we can find out if it is a file or a directory.
>>> But to know what is the name of the file/directory may not be  possible
>>> right now without traversing the entire tree and checking for the  
>>> given
>>> handle.
>>> We could possibly store the parent handle as part of the keyval  for 
>>> the
>>> given handle and work our way backwards. Sam and I had discussed the
>>> possibility of doing that for some other thing. Just not sure if  
>>> that was
>>> worth the effort or if it was useful for any other feature.
>>> But it sure seems like having that would be a good diagnostic aid  
>>> in case
>>> something bad happens..
>>> Thanks,
>>> Murali
>>>
>>>>
>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> _______________________________________________
>>>> Pvfs2-users mailing list
>>>> Pvfs2-users at beowulf-underground.org
>>>> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-users
>>>>
>>>>
>>> _______________________________________________
>>> Pvfs2-users mailing list
>>> Pvfs2-users at beowulf-underground.org
>>> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-users
>>
>> _______________________________________________
>> Pvfs2-users mailing list
>> Pvfs2-users at beowulf-underground.org
>> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-users
>>
>
> _______________________________________________
> Pvfs2-users mailing list
> Pvfs2-users at beowulf-underground.org
> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-users