raw disk size determination broken on solaris 10?

[GoogleCodeExporter]

On a solaris 10 system, scrub-2.2 properly determined device size while 2.5.2 
did not.

Original issue reported on code.google.com by garlick....@gmail.com on 14 Feb 2013 at 4:46

[GoogleCodeExporter]

Date: Wed, 13 Feb 2013 20:31:17 +0000
From: "Dombrowski, Neil" <neil.dombrowski@hp.com>
To: "garlick@llnl.gov" <garlick@llnl.gov>
Subject: disk scrub problem

[-- Error: Inconsistent multipart/signed structure! --]

I hope you're still part of the scrub project, if not my apologies for
bothering you.

I've been trying to use scrub to wipe some disks on an array attached to an
X86 server running Solaris 10. I downloaded 2.5.2 and compiled it (didn't
see any errors) using /usr/ccs/bin/make, then I tried to use it to scrub a
drive:

-# scrub /dev/rdsk/c3t4d0s2
scrub: using NNSA NAP-14.1-C patterns
scrub: warning: /dev/rdsk/c3t4d0s2 is zero length
root-P-@ir3[/dev]

-# scrub /dev/dsk/c3t4d0s2
scrub: using NNSA NAP-14.1-C patterns
scrub: padding /dev/dsk/c3t4d0s2 with 1 bytes to fill last fs block
scrub: scrubbing /dev/dsk/c3t4d0s2 -9223372036854775808 bytes
scrub: random  |scrub: /dev/dsk/c3t4d0s2: Invalid argument  |
root-P-@ir3[/dev]

I tried formatting the disk, creating a different partition that covers the
entire disk, but have the same problem:

-# scrub /dev/rdsk/c3t2d0s0
scrub: using NNSA NAP-14.1-C patterns
scrub: warning: /dev/rdsk/c3t2d0s0 is zero length

This was a disk that was originally labeled EFI, but I re-labeled it SMI
before I tried to run scrub. I don't know enough about programming to figure
out what's wrong, can you tell what my issue is?

I got my hands on a Solaris pkg scrub-2.2-sol10-x86-local and installed it,
but it would only make one pass and would then just seem to hang.

Thank you for your help,

Neil

Original comment by garlick....@gmail.com on 14 Feb 2013 at 4:48

[GoogleCodeExporter]

From: Jim Garlick [mailto:garlick@llnl.gov]
Sent: Wednesday, February 13, 2013 3:44 PM
To: Dombrowski, Neil
Subject: Re: disk scrub problem

Hi Neil,

I've tested on Solaris 10 but only with gcc.  Maybe I'm doing something
that the Sun compiler doesn't handle well (maybe the way I build for
"large file support").  Anyway the size of the device can be specified on
the command line if you want to give that a try:

  -s, --device-size size
        Override the device size (in bytes). Without this option,  scrub
        determines  media capacity using OS-specific ioctl(2) calls.  K,
        M, or G may be appended to the number to  change  the  units  to
        KiBytes, MiBytes, or GiBytes, respectively.

I'm pretty sure you want to scrub the raw device (/dev/rdsk/...) not
the other one (/dev/dsk/...).

If that doesn't work could you install gcc?  I think Sun makes it easy
with their /usr/sfw packaging, though I don't know the details as our
admins installed that stuff for us.

Let me know how you get on,

Jim

Original comment by garlick....@gmail.com on 14 Feb 2013 at 4:48

[GoogleCodeExporter]

Date: Wed, 13 Feb 2013 22:50:46 +0000
From: "Dombrowski, Neil" <neil.dombrowski@hp.com>
To: Jim Garlick <garlick@llnl.gov>
Subject: RE: disk scrub problem

[-- Error: Inconsistent multipart/signed structure! --]

Jim,
        Thanks for your quick reply. I'd forgotten that we install gcc as
part of our cfengine installation. I ran  "./configure
CC=/usr/local/bin/gcc" and then did my make/make install. It still complains
that the device is zero length. It appears that when converting the disk
label from EFI to SMI that the new Solaris partition I create is not
starting at cylinder zero (no idea why or how to fix it right now). I did as
you suggested (specifying the size), and it is running now.
        The problem I had with the scrub-2.2 version was that it would
finish the first pass but never start a second pass. It would seemingly sit
in limbo, using the same % cpu but no io on the disk. I'll see if the 2.5.2
version I compiled will have the same issue at the end of the first pass.

Thanks again,
    Neil

Original comment by garlick....@gmail.com on 14 Feb 2013 at 4:48

[GoogleCodeExporter]

From: Jim Garlick [mailto:garlick@llnl.gov]
Sent: Wednesday, February 13, 2013 5:18 PM
To: Dombrowski, Neil
Subject: Re: disk scrub problem

Does scrub-2.2 get the size right?

I'm not sure about the hang at the end of the pass, although if
you were scrubbing the /dev/dsk not the /dev/rdsk device you might
have a large cache of data in memory that has to be flushed to disk
at the end of a pass before the next one can start.  If you get there
again you could see if your disk is busy during the hang (is there
something like Linux's "iostat" on solaris?)

Jim

Original comment by garlick....@gmail.com on 14 Feb 2013 at 4:49

[GoogleCodeExporter]

Date: Thu, 14 Feb 2013 14:48:20 +0000
From: "Dombrowski, Neil" <neil.dombrowski@hp.com>
To: Jim Garlick <garlick@llnl.gov>
CC: "Bouwma, Mike" <michael.bouwma@hp.com>
Subject: RE: disk scrub problem

[-- Error: Inconsistent multipart/signed structure! --]

Jim,
        I was able to scrub the disk with v2.5.2 once I specified the size:

-# scrub -s 278G /dev/rdsk/c3t2d0s2
scrub: using NNSA NAP-14.1-C patterns
scrub: scrubbing /dev/rdsk/c3t2d0s2 298500227072 bytes (~278GB)
scrub: random  |................................................|
scrub: random  |................................................|
scrub: 0x00    |................................................|
scrub: verify  |................................................|
root-P-@nr3[/usr/local/bin]

When I used the older version 2.2 it figured out the size, not sure why it
would never start the second pass.  v2.2 did work on a previous server that
we decommissioned, so I'm thinking this had to do with the disks on this
server originally having zfs on the drive(disk labeled EFI) and re-labeling
it as SMI somehow skipped cylinder 0.

-# fdisk /dev/rdsk/c3t2d0s2
WARNING: Device /dev/rdsk/c3t2d0s2:
The device does not appear to include absolute
sector 0 of the PHYSICAL disk (the normal location for an fdisk table).
Fdisk is normally used with the device that represents the entire fixed
disk.
(For example, /dev/rdsk/c0d0p0 on x86 or /dev/rdsk/c0t5d0s2 on sparc).

Anyway, I'm able to scrub the disks now. Thank you for responding to me so
quickly, I appreciate your efforts with this.

Take care,
    Neil

Original comment by garlick....@gmail.com on 14 Feb 2013 at 4:49