Dev_Seek errors from ufsdump

2007-12-25 10:23:00

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

Comments

Got something to say?

You must be logged in to post a comment.