How do I erase disks on HPUX boxes?
John Blackburn
We have a number of HPUX 10.20, and 11.00 servers which have been
decommissioned, and our organization has a requirement that the disks be
wiped before we can dispose of the machines.
What are the best methods of erasing disks on HPUX boxes?
Cheers,
John.
<if you wish to email me you'll need to change the "qov" to "gov" in my
email address - anti spam measures>
Mikko Nahkola
> We have a number of HPUX 10.20, and 11.00 servers which have been
> decommissioned, and our organization has a requirement that the disks be
> wiped before we can dispose of the machines.
> What are the best methods of erasing disks on HPUX boxes?
Well ... there's always the simple "dd" command - sure, there's no
official zero device on HP-UX, but ... "yes | dd of=/dev/rdsk/foo
obs=64k" should work just as well even if it's a bit slower.
Of course, if you could get GNU shred (in the coreutils package
nowadays, available prebuilt from the Porting & Archive Centre but only
for 11.x), that should do a somewhat better wipe.
Neither will get disk blocks that have been marked bad, though. To get
those needs somewhat lower-level access to the disk and I don't know
anything that'd do that on HP-UX nowadays ... except maybe mediainit but
that's a bit controversial nowadays...
And, if nothing else, you could always connect the disks to a PC and
wipe there.
Depending on which kind of disks, this might require a bit of unusual
hardware in the PC (say, an Adaptec AHA-2944 / HP A5252A for HVD disks,
and so on).
--
Mikko Nahkola <mnah...@trein.ntc.nokia.com>
#include <disclaimer.h>
#Not speaking for my employer. No warranty. YMMV.
Florian Anwander
> Well ... there's always the simple "dd" command - sure, there's no
> official zero device on HP-UX, but ... "yes | dd of=/dev/rdsk/foo
> obs=64k" should work just as well even if it's a bit slower.
The inofficial ;) /dev/zero can be created by root using the command:
mknod /dev/zero c 3 0x000003
then
dd if=/dev/zero of=/dev/rdsk/....
If the disk you are wiping contains your swap or operating system be
sure, that this dd is the last thing you will do before switching off
the machine.
And be warned: there are technologies to explore data which were
overwritten several times. If you want to be sure that no one knows what
was on the disk: throw the disk in a blast furnace.
Florian
--
mail an "fanwander AT mnet MINUS online PUNKT de"
Benjamin Gawert
> We have a number of HPUX 10.20, and 11.00 servers which have been
> decommissioned, and our organization has a requirement that the disks
> be wiped before we can dispose of the machines.
>
> What are the best methods of erasing disks on HPUX boxes?
Format them with mediainit. That's better than zeroing it with dd since it
erases the whole disk incl. bad/spare sectors, it does a mediacheck which
tells You if the disk is still ok (in case You want to sell the machines),
and it already comes with the Operating system.
Benjamin
Alan D Johnson
Frank Slootweg
As Mikko mentioned, mediainit is "controversial". mediainit may make
the disk less reliable and you will not know if it did or not, so you
should *not* do that if you want to sell it/them.
For details, see the HP IT Resource Forum article "How/when (not) to
use mediainit?" of August 14, 2002. You will probably recognize the
name of the author.
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=28275
For some reason, the base article in that thread is not displayed, at
least not for me, so here it is:
How/when (not) to use mediainit?
================================
Frank Slootweg August 14, 2002 06:58 AM GMT
Lately there has been some controversy about using mediainit(1M), and
especially about when NOT use it.
It should be stressed that this controversy is NOT a question of 'right'
versus 'wrong', 'better' versus 'worse' but of different viewpoints/
opinions based on different priorities..
This article concentrates of the use of mediainit for HARD (i.e. not
'floppy', etc.) DISKS (i.e. not tapes).
Whatever you do, please READ this article BEFORE using mediainit.
This article is mainly written from MY viewpoint, which is to prevent
unneeded problems and to prevent unneeded negative impact on disk
reliability. My viewpoint is based on my experience gathered while
working (for 34 years) in customer support at HP, first on the HP1000
and since day one (of HP-UX, early 1983) on the HP9000/HP-UX.
I will describe three different scenarios, and what I think is best in
those scenarios. I will also explain WHY mediainit may make a disk less
reliable.
Please feel free to give your feedback, additions, corrections, etc.,
either here or by e-mail (frank_s...@hp.com).
I will probably not award points until the discussion is more or less
over, so please be patient.
1. Disk which used to work, but now gives I/O errors.
-----------------------------------------------------
Only use mediainit if:
- the disk can not be fixed by trained hardware people
AND
- LVM bad block relocation is NOT enabled
AND
- LVM bad block relocation CANNOT be enabled (for some REAL reason)
I.e. you basically have no other option than to try mediainit.
Even if mediainit SEEMS to 'fix' the problem (no more I/O errors), I
advise to replace the disk because it is likely that the disk is less
reliable or even unreliable (see 4. below as to why) and is more likely
to fail in the (near?) future, probably at an inconvenient time.
For details about LVM bad block relocation, see Bill Hassell's response
in this thread (see copy ("Appendix:") below):
http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x4b34eea29889d611abdb0090277a778c,00.html
Note: For most disk-arrays you will be instructed not to enable LVM bad
block relocation, but also in that case you should NOT use mediainit
because the (tools of the) array will handle it. See the documentation
of the array for details.
2. Disk has NEVER worked on THIS system AND is non-supported.
-------------------------------------------------------------
It can happen that a disk is formatted with the 'wrong' sector size,
i.e. one which is not supported by your HP-UX system. In that case
diskinfo(1M) will probably give a "size:" and/or "bytes per sector:" of
zero.
If the disk is non-supported AND you can not exchange it for a supported
disk, i.e. you basically have no other option than to try mediainit,
then mediainit MIGHT get the disk 'working'. Working in quotes, because
you will have the same reliability issues as described under 1. above
(see 4. for details).
3. Disk needs to be erased.
---------------------------
For some reason you need to 'erase' the disk, i.e. remove all data from
it.
In this scenario you should ONLY use mediainit if you intend NOT to
re-use the disk, i.e. you intend to throw it away. Why? For the same
reliability issues as described above under 1. above (see 4. for
details).
Other, more 'sensible', methods for erasing a disk are outside the scope
of this article. For details, see the ITRC Forums threads which advise
to use dd(1) reading from /dev/zero and writing to the disk, i.e.
dd if=/dev/zero of=/dev/... bs=<large>
Some example threads (just search on "/dev/zero" (that gave me 48 hits,
i.e. not too much) and perhaps also on "disk"):
http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x3c0f36e69499d611abdb0090277a778c,00.html
http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x2feeed6464a6d611abdb0090277a778c,00.html
4. WHY may mediainit make a disk less reliable?
-----------------------------------------------
This is the most controversial part. Note the use of the word "may",
i.e. not (neccessarily) "will". Some people have 'positive' experience
using mediainit, i.e. for them it seemed to solve the problem and it
seemed not to have adverse effects. Others, including myself, have had
negative experience, i.e. disks failing, i.e. giving errors or more
severe errors, 'shortly' (can be weeks) after using mediainit. Again, MY
reasoning is: WHY use mediainit when it is NOT needed and MAY cause
reliability problems?
Anyway, here is the technical information:
mediainit TRIES to do a Low-Level Format (LLF). Whether or not a LLF is
actually done depends on a number of factors, including the firmware of
the disk controller. If mediainit can not do a LLF, it will NOT say so,
so after mediainit has completed without error messages, you do NOT know
whether or not the disk was LLFed.
'Modern' disks, disks manufactured in the last 5-8 years, come pre-(LL)
formatted, meaning that the bad sectors have been relocated and all the
hardware headers (sector pre-amble and post-amble) are complete.
During manufacturing, much more PRECISE equipment than a normal disk
mechanism is used during the LLF process. If mediainit does a LLF, the
information (pre-amble, post-amble, etc.) will likely/probably be
written at a slightly different physical location on the disk. Because
the process is less precise and the old information is not completely
erased (inter-track residue), the result is a disk which may be less
reliable or even unreliable, but you have NO way of KNOWING one way or
the other.
Frank Slootweg, HP, August 14, 2002.
--------------------------------------------------------------------------------
Appendix:
=========
Bill Hassell July 03, 2002 12:46 PM GMT [ 10 pts ]
--------------------------------------------------------------------------------
fsck can *never* fix I/O errors. I/O errors are hardware failures, and
fsck is a tool to fix logical and structural errors in the directories.
The syslog error are very important to be checked and acted on ASAP.
Consider writing a cron job that looks for problems every hour or two
each day and mails the results to your sysadmin team. Something like
this:
grep -i -e crit -e warn -e err -e fail -e problem
/var/adm/syslog/syslog.log
Now, LVM is smart enough to fix this *IF* bad block relocation has been
turned on. Use lvchange -r y to turn on the feature for each logical
volume (note: some big diskarrays require this to be off and use
diskarray tools to fix the error).
Once BadBlockRelocation is on, the next attepmt to write to the bad spot
will cause the relocation to occur and all will be well again. Since you
don't have any control over whether directory blocks and metadata is
updated, newfs will handle this for you. Don't try to just restore the
data without newfs. The directory metadata is corrupted and even though
it may eventually get rewritten, some of it must be intact to know where
to put the new data.
Note that a bad spot will always stay bad (can't be read) and will get
worse with age. If this disk is not mirrored, get the Mirror/UX product,
mirror your disks and plan for a replacement. If these are old (and
likely very small) disks, look at a complete upgrade with mirroring.
Benjamin Gawert
>> Format them with mediainit. That's better than zeroing it with dd
>> since it
>> erases the whole disk incl. bad/spare sectors, it does a mediacheck
>> which
>> tells You if the disk is still ok (in case You want to sell the
>> machines),
>> and it already comes with the Operating system.
>
> As Mikko mentioned, mediainit is "controversial".
I know, the old "ll-format might destruct your drive" rumor...
> mediainit may make
> the disk less reliable
No, not really.
> and you will not know if it did or not, so you
> should *not* do that if you want to sell it/them.
>
> For details, see the HP IT Resource Forum article "How/when (not) to
> use mediainit?" of August 14, 2002. You will probably recognize the
> name of the author.
>
> http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=28275
>
[snip]
Until here it's correct.
> During manufacturing, much more PRECISE equipment than a normal disk
> mechanism is used during the LLF process. If mediainit does a LLF, the
> information (pre-amble, post-amble, etc.) will likely/probably be
> written at a slightly different physical location on the disk. Because
> the process is less precise and the old information is not completely
> erased (inter-track residue)
And this is wrong (well, it's not wrong, but waaay outdated). The effect
described here is valid ONLY for disks that use stepper motors for head
positioning. On these disks it is possible that a reformat writes not
exactly over the same position like its done on factory. But all somewhat
newer disks (at least valid since ~1995 for most disks) use voice-coil
actuators which unlike stepper motors don't use certain steps but stepless
positioning, so the effect descirbed above simply can't happen. Another
thing is that on modern disks a ll-format does NOT re-write track
informations like on old hard disks, on modern disks this information can't
be erased. If a modern disk gets a ll-format command it does either just a
zeroing/verification of the data blocks, or (like a handful disks) simply
does nothing.
I respect the authors point of view but as he already said it's mostly based
out of his very long (34yrs) experience at HP service. But it's important to
realize that during this long time his experience is based mostly on old
disk systems with stepper motor as actuator and without intelligent
controllers which was standard at these times. However, modern disks are
different, and they can't be destroyed by an ll-format.
BTW: this is based of the experience we have with hard disks. For certain
applications we develop we also use hard disk technology, and for such
things we have trained personnel and a clean room for disassembling disks.
Benjamin
Alan D Johnson
Thats why I said sledgehammers, back in the days of 30/30's you wanted
to keep disks, now, WHY BOTHER? buy GB's of mem for what HD's used to
be??, disks do not even matter by themselves, whack it with a hammer,
GOOD stress relief!
Benjamin Gawert
> Thats why I said sledgehammers, back in the days of 30/30's you wanted
> to keep disks, now, WHY BOTHER? buy GB's of mem for what HD's used to
> be??, disks do not even matter by themselves, whack it with a hammer,
> GOOD stress relief!
If the disks contained sensible data which have to be destroyed the best is
of course a physical destruction (trashing disks and melting them at
temperatures over the curie point). But if the data aren't that sensible and
the systems have to be sold running mediainit is good enough. Today IDE
disks might be generally cheap but HP9000s usually use SCSI disks which are
more expensive, and having a HP-certified disks costs even much more...
Benjamin
Frank Slootweg
> Frank Slootweg wrote:
>
>>> Format them with mediainit. That's better than zeroing it with dd
>>> since it
>>> erases the whole disk incl. bad/spare sectors, it does a mediacheck
>>> which
>>> tells You if the disk is still ok (in case You want to sell the
>>> machines),
>>> and it already comes with the Operating system.
>>
>> As Mikko mentioned, mediainit is "controversial".
>
> I know, the old "ll-format might destruct your drive" rumor...
No, not "destruct". If it would *destruct* a drive, then the subject
would not be controversial.
Yes, I know that 'modern' disks use voice-coil actuators, but the
mentioned (bad) alignment problem can still happen, because both the
stepper motors and the voice-coil actuators can position the head on the
'wrong' place on the track.
> Another
> thing is that on modern disks a ll-format does NOT re-write track
> informations like on old hard disks, on modern disks this information can't
> be erased. If a modern disk gets a ll-format command it does either just a
> zeroing/verification of the data blocks, or (like a handful disks) simply
> does nothing.
As I wrote that (amongst others) depends on the firmware of the disk
controller. Unless Joe Customer is a disk specialist *and* has insight
in the *specific* firmware of his disk(s), he can't possibly know
whether or not the ll-format was done. That is the point.
> I respect the authors point of view but as he already said it's mostly based
> out of his very long (34yrs) experience at HP service. But it's important to
> realize that during this long time his experience is based mostly on old
> disk systems with stepper motor as actuator and without intelligent
> controllers which was standard at these times. However, modern disks are
> different, and they can't be destroyed by an ll-format.
>
> BTW: this is based of the experience we have with hard disks. For certain
> applications we develop we also use hard disk technology, and for such
> things we have trained personnel and a clean room for disassembling disks.
Well, I beg to differ. My article is based on the collective expertise
of some very, very knowledgeable people, including several disk
specialists.
Anyway, the main point is that one should not use mediainit to erase
disks (i.e. the subject of this thread), because there are other methods
(see the other responses and my article) and it may do more harm than
good.
Benjamin Gawert
> Yes, I know that 'modern' disks use voice-coil actuators, but the
> mentioned (bad) alignment problem can still happen, because both the
> stepper motors and the voice-coil actuators can position the head on
> the 'wrong' place on the track.
No. Voice Coil actuators don't position on the "Wrong" place simply because
its position is adjusted by correction values generated from the read signal
amplitude. Voice coils never lie "besides the track"...
> As I wrote that (amongst others) depends on the firmware of the disk
> controller. Unless Joe Customer is a disk specialist *and* has insight
> in the *specific* firmware of his disk(s), he can't possibly know
> whether or not the ll-format was done. That is the point.
Oh, he can. If he really has one of the rare disks that do nothing the disk
content is unchanged.
> Well, I beg to differ. My article is based on the collective
> expertise
> of some very, very knowledgeable people, including several disk
> specialists.
My experience is based on the disk specialists in our company, the engineers
from several disk manufacturers that often visit us, and my own experience
with ll-formatting a lots of disks during the last ~15 years or so.
Benjamin
Frank Slootweg
> Frank Slootweg wrote:
>
>> Yes, I know that 'modern' disks use voice-coil actuators, but the
>> mentioned (bad) alignment problem can still happen, because both the
>> stepper motors and the voice-coil actuators can position the head on
>> the 'wrong' place on the track.
>
> No. Voice Coil actuators don't position on the "Wrong" place simply because
> its position is adjusted by correction values generated from the read signal
> amplitude. Voice coils never lie "besides the track"...
Of course it is a closed-loop system, but that does not mean it is
perfect. No system is. Also the systems used during production are not
perfect. They are just better. That is all I/we am/are saying.
>> As I wrote that (amongst others) depends on the firmware of the disk
>> controller. Unless Joe Customer is a disk specialist *and* has insight
>> in the *specific* firmware of his disk(s), he can't possibly know
>> whether or not the ll-format was done. That is the point.
>
> Oh, he can. If he really has one of the rare disks that do nothing the disk
> content is unchanged.
Sorry but you've lost me. "one of the rare disk that do nothing"? I am
not talking about disks which do nothing, but about disks which do/
do_not allow a ll-format and about mediainit not saying whether they do
or do not. In *any * case, mediainit *will* change the content (i.e.
data) of the disk ("writing and reading test patterns to verify media
integrity"). So after mediainit is done, the disk content *will* be
changed, but Joe Customer will not know whether or not a ll-format was
done.
>> Well, I beg to differ. My article is based on the collective expertise
>> of some very, very knowledgeable people, including several disk
>> specialists.
>
> My experience is based on the disk specialists in our company, the engineers
> from several disk manufacturers that often visit us, and my own experience
> with ll-formatting a lots of disks during the last ~15 years or so.
If you mean that you have had no negative experience with
ll-formatting, then my article does not contradict that. It however
explains that non-negative is not the same as positive:
MA> This is the most controversial part. Note the use of the word "may",
MA> i.e. not (neccessarily) "will". Some people have 'positive' experience
MA> using mediainit, i.e. for them it seemed to solve the problem and it
MA> seemed not to have adverse effects. Others, including myself, have had
MA> negative experience, i.e. disks failing, i.e. giving errors or more
MA> severe errors, 'shortly' (can be weeks) after using mediainit. Again, MY
MA> reasoning is: WHY use mediainit when it is NOT needed and MAY cause
MA> reliability problems?
David Kinsell
"Benjamin Gawert" <bga...@gmx.de> wrote in message news:c49kcc$2gehrr$1...@ID-22005.news.uni-berlin.de...
Well, sort of. No SCSI disk ever used on an hpux system (that goes back
to about 1990) has ever allowed a low-level format on the media. Nor
have they ever used stepper motors to actuate the heads. Way too slow.
So where does this myth come from that mediainit may damage the drive?
Failing drives generally start out with one or two bad sectors, and maybe the
user uses mediainit to fix up the problem. A week later, the disk is dead. Did
mediainit cause the failure? No, it was irrelevant. Many disk failures just happen
that way, first a few random bad sectors, then a flood of bad sectors show up
quickly afterwards. That old saying about how correlation doesn't prove cause
and effect really is true.
Dave
Mikko Nahkola
> "Benjamin Gawert" <bga...@gmx.de> wrote in message
>> > mediainit TRIES to do a Low-Level Format (LLF). Whether or not a LLF
>> > is
>> > actually done depends on a number of factors, including the firmware
>> > of
>> > the disk controller. If mediainit can not do a LLF, it will NOT say
>> > so,
>> > so after mediainit has completed without error messages, you do NOT
>> > know
>> > whether or not the disk was LLFed.
>> > 'Modern' disks, disks manufactured in the last 5-8 years, come
>> > pre-(LL)
>> > formatted, meaning that the bad sectors have been relocated and all
>> > the
>> > hardware headers (sector pre-amble and post-amble) are complete.
>> Until here it's correct.
> Well, sort of. No SCSI disk ever used on an hpux system (that goes back
> to about 1990) has ever allowed a low-level format on the media. Nor
> have they ever used stepper motors to actuate the heads. Way too slow.
Excuse me, but I _have_ seen disks pulled from a HP-UX system, low-level
formatted _differently_, and then reused in a PC. This was because the
PC couldn't cope with the unusual kind of low-level format used in the
HP RAID thing that HP-UX box had.
Yes, that would be a special case, but the disks _were_ used in a HP-UX
system, and _did_ allow an actual low-level format to be done - with an
Adaptec PC HBA's built-in tools, at least.
(Um. Now that ... I think we still have a bunch of untouched disks
somewhere ... should attach one of them directly to a HP-UX box and see
if mediainit does anything ... IIRC HP-UX can't cope directly with the
520 sector size or whatever it was, either.)
And, yes, we _did_ know that we could possibly just get disk-shaped
paperweights. Oh well ... AFAIK all those disks are still operational.
Benjamin Gawert
>> No. Voice Coil actuators don't position on the "Wrong" place simply
>> because its position is adjusted by correction values generated from
>> the read signal amplitude. Voice coils never lie "besides the
>> track"...
>
> Of course it is a closed-loop system, but that does not mean it is
> perfect. No system is. Also the systems used during production are not
> perfect. They are just better. That is all I/we am/are saying.
Fine. But the system failing has a lower chance of the user damaging the
disk by dropping it or killing the electronics by ESD. Or crashing the heads
by moving the computer while the disk is running, or whatever.
If mediainit is too risky for You then You shouldn't even touch a disk
because all other risks of damaging/destroying it are much bigger.
> Sorry but you've lost me. "one of the rare disk that do nothing"? I
> am
> not talking about disks which do nothing, but about disks which do/
> do_not allow a ll-format and about mediainit not saying whether they
> do
> or do not. In *any * case, mediainit *will* change the content (i.e.
> data) of the disk ("writing and reading test patterns to verify media
> integrity"). So after mediainit is done, the disk content *will* be
> changed, but Joe Customer will not know whether or not a ll-format was
> done.
And where is the problem? Even if the ll-format hasn't been done the disk is
just erased (overwritten), but still as useable as before.
>> My experience is based on the disk specialists in our company, the
>> engineers from several disk manufacturers that often visit us, and
>> my own experience with ll-formatting a lots of disks during the last
>> ~15 years or so.
>
> If you mean that you have had no negative experience with
> ll-formatting, then my article does not contradict that. It however
> explains that non-negative is not the same as positive:
And what exactly is a positive experience here? What can be more positive
than a disk that still works after ll-format?
Yes, I had no negative experience (which is the same like positive
experience in this case), and I have to ll-format quite often. For example,
for different projects we often need a bunch of disks, so the disks get
ll-formatted before working on the project, after working on the project,
and several times during the project. We have lots of disks that have been
ll-formatted over 100 times on different platforms, be it HP, Sun, x86,
whatever. Because of the kind of projects all dying disks are getting
disassembled and examined by specialists to find out why it died. Not even a
single one showed a failure because of ll-formatting.
Then there are the disks we have for more conventional use. Since a company
policy is that before a computer is allowed to change to another dept. the
disk has to be ll-formatted lots of computers (incl. their disks) also have
a nice history of ll-formats. And even here, no disk that has been ok before
failed because of ll-format.
Benjamin
Benjamin Gawert
> Well, sort of. No SCSI disk ever used on an hpux system (that goes
> back
> to about 1990) has ever allowed a low-level format on the media. Nor
> have they ever used stepper motors to actuate the heads.
Then You got different systems than we got. I remember for example our old
F-/G-/H-Class machines coming with Hewlett Packard 2GB disks (AFAIR made by
HP, not just OEM'd like today). These disks definitely had stepper motors
for disk actuators, and they definitely allowed a ll-format (we reformatted
one successfully to be used in an old AS/400).
More modern disks used in HP9000 of course don't use steppers any more but
voice coils, but they still allow to be ll-formatted.
> Way too
> slow.
No, it's not. Stepper Motors were used as disk actuators several decades
until the early 90's.
> So where does this myth come from that mediainit may damage the drive?
Certainly it's because many years ago ll-format got some negative publicity
because of IDE drives that indeed died after a ll-format (they were
unuseable). This is not valid for SCSI since the ability to overlive an
ll-format command is part of the SCSI spec since day one.
> Failing drives generally start out with one or two bad sectors, and
> maybe the
> user uses mediainit to fix up the problem. A week later, the disk is
> dead. Did
> mediainit cause the failure? No, it was irrelevant. Many disk
> failures just happen
> that way, first a few random bad sectors, then a flood of bad sectors
> show up
> quickly afterwards. That old saying about how correlation doesn't
> prove cause
> and effect really is true.
Right. A disk that's dead after a ll-format would for sure have died a short
time later even if it wouldn't have been ll-formatted.
Benjamin
David Kinsell
"Mikko Nahkola" <mnah...@trein.ntc.nokia.com> wrote in message news:slrnc6kupc....@localhost.localdomain...
Sometimes disks would support oddball sector sizes like that. More commonly,
they would present 512, 1024, 2048, etc sizes by a physical to logical block
translation. If you were able to change 520 byte sectors to 512, it was done
by similar magic, where the 520 bytes were chopped down to 512 by a translation,
not by physically rewriting the headers on the disk. You can also change interleave
factors and things of that nature at the same time. But you ain't really doing a true
low-level format, even if it looks like you are.
Frank said earlier that mediatinit will attempt to low-level format the drives. Actually,
it will just send a Format Unit command out on SCSI, and let the controller take
what actions it deems best to prepare the disk. For any disk that's of interest today,
that will consist of writing a certification pattern, then reading the data back to make
sure it's readable. If it finds an error, it adds that sector (or track or cylinder) to the
field spares list. It doesn't rewrite the formatting, and it doesn't clean out the factory
spares list. Lowest level formatting used in disk drives for at least the last 15 years
is called "embedded servo", where one or all the surfaces are written in the factory
with information that allows the tracking. The heads shipped with the disk drive
can't physically write that information, it has to be done on a special fixture.
Dave
David Kinsell
"Benjamin Gawert" <bga...@gmx.de> wrote in message news:c4ee8g$2dikul$2...@ID-22005.news.uni-berlin.de...
> David Kinsell wrote:
>
> > Well, sort of. No SCSI disk ever used on an hpux system (that goes
> > back
> > to about 1990) has ever allowed a low-level format on the media. Nor
> > have they ever used stepper motors to actuate the heads.
>
> Then You got different systems than we got. I remember for example our old
> F-/G-/H-Class machines coming with Hewlett Packard 2GB disks (AFAIR made by
> HP, not just OEM'd like today). These disks definitely had stepper motors
> for disk actuators,
You'd have to be more specific about the disk. Not even the 200 meg Rodime
piece of garbage used on workstations had a stepper motor in it. HP made some
generic 1 and 2 gig drives before getting blown out of the disk business, but
they used voice coils, like this one:
http://marina.mfarris.com/theref/hard_drives/h_hp-c2247-001.html
Maybe they slipped a 5 1/4" drive in there with stepper motors, but I really
don't think so. Certainly not at 2 gigs.
> and they definitely allowed a ll-format (we reformatted
> one successfully to be used in an old AS/400).
>
> More modern disks used in HP9000 of course don't use steppers any more but
> voice coils, but they still allow to be ll-formatted.
Nope. See my response to Mikko.
>
> > Way too
> > slow.
>
> No, it's not. Stepper Motors were used as disk actuators several decades
> until the early 90's.
Not on SCSI disks used on hpux systems, which is what I said.
>
> > So where does this myth come from that mediainit may damage the drive?
>
> Certainly it's because many years ago ll-format got some negative publicity
> because of IDE drives that indeed died after a ll-format (they were
> unuseable). This is not valid for SCSI since the ability to overlive an
> ll-format command is part of the SCSI spec since day one.
>
> > Failing drives generally start out with one or two bad sectors, and
> > maybe the
> > user uses mediainit to fix up the problem. A week later, the disk is
> > dead. Did
> > mediainit cause the failure? No, it was irrelevant. Many disk
> > failures just happen
> > that way, first a few random bad sectors, then a flood of bad sectors
> > show up
> > quickly afterwards. That old saying about how correlation doesn't
> > prove cause
> > and effect really is true.
>
> Right. A disk that's dead after a ll-format would for sure have died a short
> time later even if it wouldn't have been ll-formatted.
That indeed was the point.
Dave
Mikko Nahkola
> "Benjamin Gawert" <bga...@gmx.de> wrote in message
>> > So where does this myth come from that mediainit may damage the drive?
>> Certainly it's because many years ago ll-format got some negative publicity
>> because of IDE drives that indeed died after a ll-format (they were
>> unuseable). This is not valid for SCSI since the ability to overlive an
>> ll-format command is part of the SCSI spec since day one.
Well, there have been other spec violations also ...
>> > Failing drives generally start out with one or two bad sectors, and
>> > maybe the
>> > user uses mediainit to fix up the problem. A week later, the disk is
>> > dead. Did
>> > mediainit cause the failure? No, it was irrelevant. Many disk
>> > failures just happen
>> > that way, first a few random bad sectors, then a flood of bad sectors
>> Right. A disk that's dead after a ll-format would for sure have died a short
>> time later even if it wouldn't have been ll-formatted.
> That indeed was the point.
It's just funny how, in -98, I did run mediainit on a bunch of 2GB disks
(in 712 workstations). None of these had reported any bad sectors
earlier, and in all cases, the mediainit failed to finish, _and_ all
disks seemed to have become permanently unusable - no command would seem
to reach the disk surface after that...
I _would_ classify that as mediainit killing the disks. However, I sort
of suspect that the problem might not have been with the head alignment
or even bad sectors or anything like that ... more like the disk
controller, possibly firmware.
Wouldn't be the only defective batch of disks that we've received from
HP. (Don't get me wrong, same thing with everyone else too ... but my
experience is mostly with HP equipment.)
And at least one later batch was fixed with a disk firmware upgrade
campaign...