Thanks to Dave Mitchell for pointing me towards the solution to my problem (duh!). His suggestion helped me to determine that ufsrestore was spending an extreme amount of time Processing zero length files (that probably shouldn't have been there in the first place). After stopping ufsrestore and re-starting it minus the aforementioned files the restore completed in a couple of hours. > I am running a Sun Netra with 2x300 Mhz procs, OS is 5.6. I have had > to restore a 4.8 Gb filesystem to a raid 5 array due to the failure of > 2 drives. The restore is running with no error messages displayed from > a DLT7000 drive. Problem is this, the restore has been running for 32 > hours and has 200 Mb to go. Currently, the restore is proceeding at > the rate of 10k every 5 minutes or so. The restore started out by > writing an esitmated 60 to 80 percent of the data in the first hour or > so, since then the rate has slowed consistently with the passage of > time. The processor utilization has increased from an initial 2% > slowly to 48% now. I have had to restore relatively small user > directories in the past (100 - 500mb) that took some time (~1.5hr) but > nothing like this. Try running # truss -d -p NNN where NNN is the process-id of the ufsrestore process, to see where the process is spending most of its time (is it hanging waiting for data from the tape, or ...) Dave. _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Fri Jul 19 16:55:46 2002
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:42:49 EST