Original question:
> G'day all,
> We have a client that has been experiencing dev_seek errors from
> ufsdump. I have looked up on SunSolve (although my copy is not upto date)
> but either Im going blind in my old age or there's no solution in my
> copy. Here's the bug report from SunSolve
>
> Bug Id: 4015300
> Category: sysadmin
> Subcategory: dump_restore
> State: integrated
> Synopsis: ufsdump results in dev_seek errors
> Description:
> When using ufsdump to back up /var on jurassic the following is received
> (jurassic 1# ufsdump 0bfu 126 firefight:/dev/rmt/0bn /var):
>
> DUMP: NEEDS ATTENTION: Cannot open `firefight:/dev/rmt/0bn'. Do you want to
> retry the open?: ("yes" or "no") YES
> DUMP: Volume 2 begins with blocks from inode 3884718
> DUMP: 42.65% done, finished in 5:36
> DUMP: 44.45% done, finished in 5:24
> DUMP: 46.25% done, finished in 5:13
> DUMP: 48.06% done, finished in 5:02
> .
> .
> .
> DUMP: Warning - block 1080189556 is beyond the end of `/dev/md/rdsk/d610'
> DUMP: bread: dev_seek error
> DUMP: Warning - block 1651667564 is beyond the end of `/dev/md/rdsk/d610'
> DUMP: bread: DEV_LSEEK2 error
> DUMP: Warning - cannot read sector 2195776576 of `/dev/md/rdsk/d610'
> DUMP: bread: DEV_LSEEK2 error
> .
> .
> .
> DUMP: More than 32 block read errors from dump device `/dev/md/rdsk/d610'
> DUMP: NEEDS ATTENTION: Do you want to attempt to continue? ("yes" or "no")
> Work around:
> None.
Solution:
Sorry to get you folks out there confused, but the example above is
from Sunsolve. Alot of people suggested in doing an fsck on the filesystem
first. A couple of people also suggested in making sure there is no overlap
between slices on the disks. All the suggestions has been done with no
luck.
Wales Wong (wawong@oliv1.ouhk.edu.hk) seemed to have the answer (in my case).
He said that Patch 104490-05 claims to fix this problem.
Jim Harmon (jim@telecnnct.com) also said:
The last time I saw this type of problem one of 2 things was true:
IT was a Seagate Drive that was out-of-rev. (You can uprev
seagate EEPROMs from a PC with a SCSI card using Seagate's
update program. It won't change data on the disk, just the
driver)
OR
IT was a corrupted partition table.
(This was a situation where a partition table was setup
differently from the "default" partition table, and the
"label" wasn't saved. Then, at some other time, someone
used the format command, got a message that the table hadn't
been saved, and hit "save label", rewriting the changed table
with a default table. Fortunately, we had a printed copy of
the custom table setup, and simply restoring the correct
partition information and saving THAT table stopped the
errors.)
Thanks to the following people for their help.
Tom Erickson <terickso@pop500.gsfc.nasa.gov>
David Evans <djevans@au.oracle.com>
Rose, Robert <Robert.Rose@ag.gov.au>
Heidi Burgiel <burgiel@math.uic.edu>
--- Jason Pong (jase@gcs.com.au) Graphics Computer Systems Pty Ltd, Australia Ph: +61-3-9888-8522 Fax: +61-3-9888-8511
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:40 CDT