headers
Number Cruncher | 10 Jul 2006 13:29

Re: Data corruption?

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
(Continue reading)

Permalink | Reply |
headers
Murali Vilayannur | 13 Jul 2006 10:31
Favicon

Re: Data corruption?

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:
(Continue reading)

Permalink | Reply |
headers
Rob Ross | 13 Jul 2006 16:50
Favicon

Re: Data corruption?

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.

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
(Continue reading)

Permalink | Reply |
headers
Sam Lang | 13 Jul 2006 17:21
Favicon

Re: Data corruption?


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.
(Continue reading)

Permalink | Reply |
headers
Number Cruncher | 13 Jul 2006 18:08

Re: Data corruption?

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:
>>
(Continue reading)

Permalink | Reply |
headers
Rob Ross | 13 Jul 2006 20:02
Favicon

Re: Data corruption?

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.
>>
(Continue reading)

Permalink | Reply |
headers
Murali Vilayannur | 13 Jul 2006 17:06
Favicon

Re: Data corruption?

Hi Rob,

> directory/metafile is that you have to change them all in the event of a
> rename. Gets nasty.

Hmm.. Right.. But you have to change it only for the object being renamed
right not for the entire hierarchy underneath that object if it is a
directory?
thanks,
Murali

>
> 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.
(Continue reading)

Permalink | Reply |

Gmane