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. > > 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 > >> [email protected] > >> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-users > >> > >> > > _______________________________________________ > > Pvfs2-users mailing list > > [email protected] > > http://www.beowulf-underground.org/mailman/listinfo/pvfs2-users > > > > _______________________________________________ Pvfs2-users mailing list [email protected] http://www.beowulf-underground.org/mailman/listinfo/pvfs2-users
