[Pvfs2-users] Data corruption?

[Rob Ross]

Hi Simon,

Yes, each handle is unique for a given file system.

It might be useful to modify pvfs2-validate (as seen on pvfs2-developers 
recently, from Phil et. al.) to track down a filename based on a handle, 
for doing exactly what Simon is talking about.

Rob

Number Cruncher wrote:
> 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
>