The db_load program was modified using the instructions in doc/db-recovery.txt given in the latest pvfs release. Should I be worried about the following lines from this file?
The dataspace_attributes.db file requires a different modification (not provided here). Doug At Fri, 19 Mar 2010 10:28:03 -0400, Phil Carns wrote: > > Oh, I guess that db_verify doesn't need to be modified if you are just > using the -o argument. db_load still has to be modified, though. > > -Phil > > Phil Carns wrote: > > Hi Doug, > > > > Did you modify all three of db_dump, db_load, and db_verify with the > > comparison function that PVFS uses for that db? > > > > -Phil > > > > Doug Johnson wrote: > >> Hi Phil, > >> > >> I probably should have tried the latest version first, I picked the > >> older version that matched what was installed on the system out of > >> an abundance of caution. > >> > >> I've installed a modified db-4.8.26. There was some progress in the > >> dump/restore procedure, > >> > >> opt2326:/fs/pvfs/pvfs/5810ab5d> type db_dump > >> db_dump is hashed (/usr/local/pvfs-db-4.8.26/bin/db_dump) > >> opt2326:/fs/pvfs/pvfs/5810ab5d> db_dump -r \ > >>> -f /tmp/dataspace_attributes.out \ > >>> dataspace_attributes.db > >> opt2326:/fs/pvfs/pvfs/5810ab5d> echo $? > >> 0 > >> opt2326:/fs/pvfs/pvfs/5810ab5d> db_load -f > >> /tmp/dataspace_attributes.out test.db > >> opt2326:/fs/pvfs/pvfs/5810ab5d> mv dataspace_attributes.db \ > >> dataspace_attributes.db.bad > >> opt2326:/fs/pvfs/pvfs/5810ab5d> db_verify -o dataspace_attributes.db > >> opt2326:/fs/pvfs/pvfs/5810ab5d> echo $? > >> 0 > >> > >> However, when attempting to start the pvfs server it exits immediately > >> with, > >> > >> [D 03/18 17:02] PVFS2 Server version 2.8.1 starting. > >> [E 03/18 17:02] dbpf_dspace_iterate_handles_op_svc: Invalid argument > >> [E 03/18 17:02] Error adding handle range > >> 4099276460824344803-5124095576030431002 to > >> filesystem pvfs2-fs > >> [E 03/18 17:02] Error: Could not initialize server interfaces; aborting. > >> [E 03/18 17:02] Error: Could not initialize server; aborting. > >> > >> The logs with EventLogging set to 'all' are attached. I've rechecked > >> the bdb files, and all verify with no errors. > >> > >> Doug > >> > >> > >> At Thu, 18 Mar 2010 15:08:52 -0400, > >> Phil Carns wrote: > >>> Hi Doug, > >>> > >>> I haven't seen db_dump fail altogether like that before. I can make > >>> some suggestions that you may want to try, though. You should probably > >>> back up the current corrupted db first to make sure things don't get > >>> worse. > >>> > >>> The first thing I would suggest is to try a newer version of berkeley db > >>> for db_dump, since you are having to build that tool from scratch > >>> anyway. Newer versions of bdb can read the same format, and maybe there > >>> is a chance that the verification/recovery has improved since 4.3. > >>> > >>> You can also try db_recover as well (perhaps with -c?). That tool is > >>> really meant to recover transactions (which is not the issue here), but > >>> maybe it can shed more light on the verification problem. > >>> > >>> Finally in db_dump, you can try -R instead of -r. I would save that as > >>> a last resort, because I think it may recover unwanted (bogus) data as > >>> well. > >>> > >>> -Phil > >>> > >> > > > > > _______________________________________________ Pvfs2-users mailing list [email protected] http://www.beowulf-underground.org/mailman/listinfo/pvfs2-users
