About Palmers HDDs heads swap

[Corsari]

Hello friends

I had this kind of info:


"translator is in some manner "linked" with the serial number of the heads

so if you will change JUST (only) the heads, you'll read ONLY x00 from all users data LBAs"


do you know something about this?

have you successfully swapped heads on WD10SMZW or WD10SPZX (both have board full size model 800069) or on WD20SMZW ( board small size 800067 and a sticker as cover as for the Seagate Rosewood )


This post of mine is also related with this ---> https://forum.acelaboratory.com/viewtop ... 686#p36686 <--- have you experienced this behavior?

Thank you

[shahij]

I solved several Palmar already

[Corsari]

Hello Shashij

what kindly but exactly do you mean?

That you swapped heads without issues?
Mean straight heads swap without e.g. any module modification?

Thank you

[jono-ats]

Hello friends

I had this kind of info:


"translator is in some manner "linked" with the serial number of the heads

so if you will change JUST (only) the heads, you'll read ONLY x00 from all users data LBAs"

do you know something about this?

Thank you

I believe these Palmers are shingled media drives. When you are seeing all 00s there is a problem with the secondary translator initialization. It may be that the swapped heads aren't 100% compatible, or else the FW is corrupted.

In my experience, Palmer and Charger head swaps are straight forward - no firmware mods are required (the FW is locked anyway). I've only seen one type of Palmer head / slider, but Chargers use more than one type, so there is a greater chance of a mismatch.

[shahij]

Its straight forward.

00 is responsible for fw issue or incompatibility

[Corsari]

Ouch
So
l since I have swapped nothing

looks like a FW issue

maybe too many bad sectors and related consequences


or?

weak heads?

or either the two?

some sectors with HEX values are read at the 500M area by head #0

[Doomer]

Translator is not linked to serial number of the heads, heads can be changed.
However translator can killed by the drive if the drive has unstable reading

If a drive returns 00s on ALL the sectors then data is gone and probably unrecoverable
If a drive returns 00s on SOME sectors but data on others, then it is completely NORMAL situation

[fzabkar]

Is the SA recorded with SMR? Just curious.

[Corsari]

...
If a drive returns 00s on SOME sectors but data on others, then it is completely NORMAL situation

well, this is the case

so it makes sense to believe that heads are weak and in the outer circumference they are not reading

I'll try the full test

[jono-ats]

Is the SA recorded with SMR? Just curious.

Why wouldn't it be?

Here is a link to a white paper on how SMR & HelioSeal™ technology works:

https://documents.westerndigital.com/co ... nology.pdf

[Dananjaya]

same discussion.


https://forum.dolphindatalab.com/thread-3750.html

note-
sometimes this link will not work without user passwords. not sure.

[pepe]

Why wouldn't it be?

coz it would be ridiculous.
SA is not shingled.
pepe

[fzabkar]

Is the SA recorded with SMR? Just curious.

Why wouldn't it be?

I would think that HDD manufacturers would go to greater lengths to protect the integrity of the System Area (SA). AIUI, the SA is generally recorded with lower sectors per track (SPT) than the adjacent user area (UA). I would expect that a 512-byte sector size would still be the norm, hopefully with more ECC bits that the UA.

ISTM that SMR would introduce undesirable complexity during SA writes. I can't even imagine what SA caching would entail.

Consequently, should a particular track need to be modified or rewritten, the entire “band” of tracks (zone) must be re-written. Because the modified data is potentially under another “shingle” of data, direct modification is not permitted, unlike traditional CMR drives. In the case of SMR, the entire row of shingles above the modified track needs to be rewritten in the process.

As you are a WD "partner", perhaps your partner would be able to explain to you how it all works ... at the SA level.