Hi,

I have a problem when I backup my system (/ /usr and /var) with ufsdump,
I have an error :

> DUMP: bread: dev_seek error: Error 0
> DUMP: bread: dev_seek error: Error 0
> DUMP: bread: dev_seek error: Error 0
> DUMP: bread: dev_seek error: Error 0
> DUMP: bread: dev_seek error: Error 0
> DUMP: Warning - block 1820510832 is beyond the end of
`/dev/rdsk/c0t0d0s3'
> DUMP: Warning - block 1621925620 is beyond the end of
`/dev/rdsk/c0t0d0s3'

I have called the SUN support and they told me that ufsdump should be used
with unmounted FS.
So for the system I must boot on CDROM or use the snapshot.
It's not an hardware problem, because there is no message in
/var/adm/messages, iostat is ok and fsck also (Dixit SUN support)

I will do what SUN tells me, but I would like to know what method I must use
with Solaris prior 8 on servers which cannot be stopped easily.

Thank you


Philippe

PS : Sorry for my english !

In article <41ab02a8$0$2123$626a14ce@news.free.fr>, "Philippe Mary" <philippe.mary@pasdenvoi.fr> writes:
> Hi,
>
> I have a problem when I backup my system (/ /usr and /var) with ufsdump,
> I have an error :
>
> > DUMP: bread: dev_seek error: Error 0
> > DUMP: bread: dev_seek error: Error 0
> > DUMP: bread: dev_seek error: Error 0
> > DUMP: bread: dev_seek error: Error 0
> > DUMP: bread: dev_seek error: Error 0
> > DUMP: Warning - block 1820510832 is beyond the end of
> `/dev/rdsk/c0t0d0s3'
> > DUMP: Warning - block 1621925620 is beyond the end of
> `/dev/rdsk/c0t0d0s3'
>
> I have called the SUN support and they told me that ufsdump should be used
> with unmounted FS.

This is not the problem.

> So for the system I must boot on CDROM or use the snapshot.
> It's not an hardware problem, because there is no message in
> /var/adm/messages, iostat is ok and fsck also (Dixit SUN support)
>
> I will do what SUN tells me, but I would like to know what method I must use
> with Solaris prior 8 on servers which cannot be stopped easily.
>

Dont waist your time!

You have somehow managed to create a mismatching disk label (partition
map), that shows a smaller slice compared to the slice where your file
system has been created.

Run format; in the partition menu carefully check for overlapping
partitions.
Probably you have overlapping partitions of different size, and have
created the file system with a bigger size than it is mounted.

Maybe you have a wrong device name in /etc/vfstab; the rdsk device
should always match the dsk device name!


--
Michael Tosch
IT Specialist
Managed Services Germany
Hewlett-Packard GmbH
Phone: +49 2407 575 313
Mail: michael.tosch:hp.com

Thank you for your answer.

I checked what you told but all seems to be correct

Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c0t0d0s3 2206755 950586 1212034 44% /var

Part Tag Flag Cylinders Size Blocks
0 root wm 2127 - 3119 1.37GB (993/0/0) 2868777
1 swap wu 0 - 2126 2.93GB (2127/0/0)
6144903
2 backup wm 0 - 24619 33.92GB (24620/0/0) 71127180
3 var wm 3120 - 4679 2.15GB (1560/0/0) 4506840
4 unassigned wm 0 0 (0/0/0)
0
5 unassigned wm 4680 - 6097 1.95GB (1418/0/0) 4096602
6 usr wm 6098 - 8012 2.64GB (1915/0/0) 5532435
7 unassigned wm 8013 - 8069 80.41MB (57/0/0) 164673

/dev/dsk/c0t0d0s3 /dev/rdsk/c0t0d0s3 /var ufs 1
no -


Philippe

In article <41ab2a11$0$2108$626a14ce@news.free.fr>, "Philippe Mary" <philippe.mary@pasdenvoi.fr> writes:
> Thank you for your answer.
>
> I checked what you told but all seems to be correct
>
> Filesystem kbytes used avail capacity Mounted on
> /dev/dsk/c0t0d0s3 2206755 950586 1212034 44% /var
>
> Part Tag Flag Cylinders Size Blocks
> 0 root wm 2127 - 3119 1.37GB (993/0/0) 2868777
> 1 swap wu 0 - 2126 2.93GB (2127/0/0)
> 6144903
> 2 backup wm 0 - 24619 33.92GB (24620/0/0) 71127180
> 3 var wm 3120 - 4679 2.15GB (1560/0/0) 4506840
> 4 unassigned wm 0 0 (0/0/0)
> 0
> 5 unassigned wm 4680 - 6097 1.95GB (1418/0/0) 4096602
> 6 usr wm 6098 - 8012 2.64GB (1915/0/0) 5532435
> 7 unassigned wm 8013 - 8069 80.41MB (57/0/0) 164673
>
> /dev/dsk/c0t0d0s3 /dev/rdsk/c0t0d0s3 /var ufs 1
> no -
>

Yes, this looks correct.
And the blocks stated in the warning message are *far* beyond the disk
capacity.

If fsck -n does not show severe errors like "DUPs", then maybe Sun is
right, and open files really can show these messages.

fuser -C /
fuser -C /var
fuser -C /usr

should show the processes that hold files open.

The command
init S
or
init 0
should be enough to kill the process with open files.

If there are still open files, you can manually kill them
(do an echo $$ first to not kill your shell; instead, cd to
another file system).

You should also watch out for known UFS problems, e.g.
at http://sunsolve.sun.com

--
Michael Tosch
IT Specialist
Managed Services Germany
Hewlett-Packard GmbH
Phone: +49 2407 575 313
Mail: michael.tosch:hp.com

Michael Tosch wrote:
> In article <41ab2a11$0$2108$626a14ce@news.free.fr>, "Philippe Mary" <philippe.mary@pasdenvoi.fr> writes:
>
>>Thank you for your answer.
>>
>>I checked what you told but all seems to be correct
>>
>>Filesystem kbytes used avail capacity Mounted on
>>/dev/dsk/c0t0d0s3 2206755 950586 1212034 44% /var
>>
>>Part Tag Flag Cylinders Size Blocks
>> 0 root wm 2127 - 3119 1.37GB (993/0/0) 2868777
>> 1 swap wu 0 - 2126 2.93GB (2127/0/0)
>>6144903
>> 2 backup wm 0 - 24619 33.92GB (24620/0/0) 71127180
>> 3 var wm 3120 - 4679 2.15GB (1560/0/0) 4506840
>> 4 unassigned wm 0 0 (0/0/0)
>>0
>> 5 unassigned wm 4680 - 6097 1.95GB (1418/0/0) 4096602
>> 6 usr wm 6098 - 8012 2.64GB (1915/0/0) 5532435
>> 7 unassigned wm 8013 - 8069 80.41MB (57/0/0) 164673
>>
>>/dev/dsk/c0t0d0s3 /dev/rdsk/c0t0d0s3 /var ufs 1
>> no -
>>
>
>
> Yes, this looks correct.
> And the blocks stated in the warning message are *far* beyond the disk
> capacity.
>
> If fsck -n does not show severe errors like "DUPs", then maybe Sun is
> right, and open files really can show these messages.
>
> fuser -C /
> fuser -C /var
> fuser -C /usr

Err... -C is cased incorrectly. Should be -c

> should show the processes that hold files open.
>
> The command
> init S
> or
> init 0
> should be enough to kill the process with open files.

Michael, the OP said "with Solaris prior 8 on servers which
cannot be stopped easily". I suspect that the init
suggestions above might stop the servers "easily" ;-)

> If there are still open files, you can manually kill them
> (do an echo $$ first to not kill your shell; instead, cd to
> another file system).

fuser -ck may be the OP's friend. I still believe that fuser
should have really been "fu". The options would have been
much more entertaining ;-)

> You should also watch out for known UFS problems, e.g.
> at http://sunsolve.sun.com

I hope that the maintainers of sunsolve.sun.com don't suffer
too many UFS problems ;-)

Philippe Mary (philippe.mary@pasdenvoi.fr) wrote:
: Thank you for your answer.

: I checked what you told but all seems to be correct

: Filesystem kbytes used avail capacity Mounted on
: /dev/dsk/c0t0d0s3 2206755 950586 1212034 44% /var

: Part Tag Flag Cylinders Size Blocks
: 0 root wm 2127 - 3119 1.37GB (993/0/0) 2868777
: 1 swap wu 0 - 2126 2.93GB (2127/0/0) 6144903
: 2 backup wm 0 - 24619 33.92GB (24620/0/0) 71127180
: 3 var wm 3120 - 4679 2.15GB (1560/0/0) 4506840
: 4 unassigned wm 0 0 (0/0/0) 0
: 5 unassigned wm 4680 - 6097 1.95GB (1418/0/0) 4096602
: 6 usr wm 6098 - 8012 2.64GB (1915/0/0) 5532435
: 7 unassigned wm 8013 - 8069 80.41MB (57/0/0) 164673


I dunno the answer to your problem but this doesn't look right to me, mostly
with s2.

If the drive is a 36GB, the 24620 (cylinders) under blocks is close to
double what I think it should be. My 18's, depends on who made them, have
7500 to 9300. Double that and you can see why I think it's off.

Even if that is correct, where is the rest of your space? You have 24620
cylinders and only assigned 0-8069.

If you did like that on purpose, no problem, but if it isn't a 36GB, that
data defined on s2 might be screwing up the works.

Just seems odd.

-bruce
bje@ripco.com

In article <cog88t$g9c$1@e250.ripco.com>, bje@ripco.com (Bruce Esquibel) writes:
> Philippe Mary (philippe.mary@pasdenvoi.fr) wrote:
> : Thank you for your answer.
>
> : I checked what you told but all seems to be correct
>
> : Filesystem kbytes used avail capacity Mounted on
> : /dev/dsk/c0t0d0s3 2206755 950586 1212034 44% /var
>
> : Part Tag Flag Cylinders Size Blocks
> : 0 root wm 2127 - 3119 1.37GB (993/0/0) 2868777
> : 1 swap wu 0 - 2126 2.93GB (2127/0/0) 6144903
> : 2 backup wm 0 - 24619 33.92GB (24620/0/0) 71127180
> : 3 var wm 3120 - 4679 2.15GB (1560/0/0) 4506840
> : 4 unassigned wm 0 0 (0/0/0) 0
> : 5 unassigned wm 4680 - 6097 1.95GB (1418/0/0) 4096602
> : 6 usr wm 6098 - 8012 2.64GB (1915/0/0) 5532435
> : 7 unassigned wm 8013 - 8069 80.41MB (57/0/0) 164673
>
>
> I dunno the answer to your problem but this doesn't look right to me, mostly
> with s2.
>
> If the drive is a 36GB, the 24620 (cylinders) under blocks is close to
> double what I think it should be. My 18's, depends on who made them, have
> 7500 to 9300. Double that and you can see why I think it's off.
>
> Even if that is correct, where is the rest of your space? You have 24620
> cylinders and only assigned 0-8069.
>
> If you did like that on purpose, no problem, but if it isn't a 36GB, that
> data defined on s2 might be screwing up the works.
>
> Just seems odd.
>

IMHO the table is ok. The cylinders must be multiplied by sec/cyl and heads.

s2 has 71127180 512byte blocks, this makes

71127180 / 2 / 1024 / 1024 = 33 Gigabyte, what is also directly displayed.

It is true that 20Gigabyte are not assigned to partitions, but this is no
real problem.
It is further unsual that the / partition does not start at block 0. But
this is no real problem either.

--
Michael Tosch
IT Specialist
Managed Services Germany
Hewlett-Packard GmbH
Phone: +49 2407 575 313
Mail: michael.tosch:hp.com

Bruce Esquibel wrote:

> If the drive is a 36GB, the 24620 (cylinders) under blocks is close to
> double what I think it should be. My 18's, depends on who made them, have
> 7500 to 9300. Double that and you can see why I think it's off.

The number of cylinders is not directly related to the size of the disk.
For Sun provided disks
9G -> 4924
18G -> 7506
36G -> 24620
72G -> 14087
so the 24620 figure seen by the OP is correct.

John Howells