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