anybody else Got Drive With ZERO DEFECT

[prodata]

Just want to share...

Last month I got one case MT N40P 40 GB Refurbish Drive. Need to save data.
Got SA Problem after repait its SA. Found Drive Have No Defect in Defect List.
Both 18H / 1BH / and 33H report as ZERO Defect. Very Strange. simply check its data integrity found 2 Partition was NTFS and MFT was stored in Cluster 0C00000H. Simply check and Found MFT Header and jump to second Partition see all BR and MFT is Good.. WOW this is very strange it really Got ZERO Defect.

Today I got same case again. receive one N40P 40 GB refurbish got ZERO Defect too...

Just want to know...
is there sombody else got DRIVE with ZERO DEFECT. ???

AP

[pepe]

Hi,

that's virtually impossible But I believe U.
are both copies of Plist empty?

pepe

[prodata]

Both COPY is same. I have check DATA COPY 0 anda DATA COPY 1 is same. Module 18H/1BH just content header with zero Content. ULIST report 18H just have one Sector.
there is also same in 33H just content Header. It is virtually impossible but it real 0 Defect

[scratchy]

Check the translator module. This is where the real defect mapping happens. You can clear PList and GList without affecting translator.

[scratchy]

Ahh sorry, just read the second line.

What about the second copy of the firmware - I must say I have never seen this either.
Has the drive been anywhere else where they may have cleared these modules in an attempt at recovery ?

[hddguy]

I would ask customer if a previous DR company had it. Maybe it is not intentional, and maybe have a copy of modulr 18 and/or 33?

[HDD Spaz]

Ahh sorry, just read the second line.

What about the second copy of the firmware - I must say I have never seen this either.
Has the drive been anywhere else where they may have cleared these modules in an attempt at recovery ?

This is what I was thinking. Maybe you could rephrase it - Has the drive been anywhere else where they may have cleared these modules in an attempt to prevent recovery

[N.C.]

Hello,

I have played some (26) equal calypso, i have played a little with P list as well.
So, some drive can be good, and error-free after i clear the P list, regen the translator, and test the drive under linux.

This means for me, maxtor marks the lean sectors in to the P as well, not just the real bads!

Additionally, in refurbished drives, wich have disabled zones, the remaiming zones can be good without the original p list...

I have not seen this, but i can imagine easily.

Regards,
Janos

[pepe]

NC: If U regen translator, Plist is restored to its factory released state, so the drive is 'error free' again.


If Prodata was facing with somebody erased the Plist, the user area would have contained slips and the FS could not be accessed in simple way like He did in this case.

pepe

[N.C.]

NC: If U regen translator, Plist is restored to its factory released state, so the drive is 'error free' again.

pepe

I have checked, the p list gets empty.

J

[pepe]

check again!
At least if Hlist is not empty Plist won't be empty after regen.

we can argue about it later...
pepe

[craig6928]

all drives have defects from new
no drives are error free

possible you got a weird problem

[scratchy]

If it's a 40 GB there are no disabled zones. Would be interesting to see a dump of the firmware on this drive - can you upload ?

[scratchy]

Has anyone ever run the self test then checked the fw ?
Just a thought as Prodata said this was a refurb..

[N.C.]

check again!
At least if Hlist is not empty Plist won't be empty after regen.

we can argue about it later...
pepe

However, N40P uses the Plist when i read it, i have experienced that.
I have seen some drive, wich have bads in the P.
The drive can behave different before and after the P gets bad again during the imaging.
(i needed to build one quick compare module into my imaging sw to check the drive integrity in more times in some cases....
I have one drive wich gets slipped during the imaging. )

Janos

[prodata]

ok I will tell some of my step,
at first I think somebody have modify it caused SA got problem in Module P/GList,DMCS,DISK,RZTBL,SEC. it is very strange when i check to 33H. just content Header. I think it is impossible. I do not have original Module of Defect table. Then I think I will repair it with 0 defect. just write all corrupt module with Good module and then Clear P/Glist. turn off and turn on drive detect and I can access data. turn to Maxtor Utility and run regen. Caused 33H is empty regen done in seconds. View Plist and Glist. it is EMPTY.
this drive just have one partition FAT32, I need to clone it to check data integrity, after clone done with skip bad sector, using Rstudio scanning FAT32 FS after done I check its data. ALL data seem Good and ALL directory can be seen as well. I check about 20 file Document and got its correct address. One doc File was stored in sector 76.xxx.xxx and the address is correct for the FILE... SO I think it really got zero Defect.

Here I attach backup Module original before any modification. you can check module 33H and you will see it just content header with 0 content.

http://www.megaupload.com/?d=GUWH3U39
Thanks

Aping

Attachments

Maxtor 6E040L0-NAR61590-E10NLSVE.rar

(1.72 MiB) Downloaded 428 times

[prodata]

ok I will tell some of my step,
at first I think somebody have modify it caused SA got problem in Module P/GList,DMCS,DISK,RZTBL,SEC. it is very strange when i check to 33H. just content Header. I think it is impossible. I do not have original Module of Defect table. Then I think I will repair it with 0 defect. just write all corrupt module with Good module and then Clear P/Glist. turn off and turn on drive detect and I can access data. turn to Maxtor Utility and run regen. Caused 33H is empty regen done in seconds. View Plist and Glist. it is EMPTY.
this drive just have one partition FAT32, I need to clone it to check data integrity, after clone done with skip bad sector, using Rstudio scanning FAT32 FS after done I check its data. ALL data seem Good and ALL directory can be seen as well. I check about 20 file Document and got its correct address. One doc File was stored in sector 76.xxx.xxx and the address is correct for the FILE... SO I think it really got zero Defect.

Here I attach backup Module original before any modification. you can check module 33H and you will see it just content header with 0 content.

http://www.megaupload.com/?d=GUWH3U39
Thanks

Aping