Rosewood : Media Cache MCMT Solutions

[Amarbir[CDR-Labs]]

Hello,

  I would like to know how to use The Following

MCMT/Parser

MCMT/Edit

MCMT\Extent Edit

MCMT\Import Extent Info .

                 Some times back i saw a discussion here but i seem to have lost it  ,I see acelab using these quite a lot ,Today i had a case were i was getting a error that MCMT is unable to parse itself and i was able to read MCMT Till 0x000ff0 All BAD an then till end all ok ,Both copies same .I did nothing just restarted drive and the drive started reconstructing mcmt and i got sector access that was missing ,But i have lost a lot of info in this drive ,I think the drive did it itself as i had unlocked it  ,I think this is the reason we should use Write protection ,I see 5 different sections in work with flash rom image section ,I did save old mcmt 348 sysfile any luck i can get data back the way it should be ,I am out of acelab support right now

   

  

[pbzcbf...@gmail.com]

Could you upload the old and new 348 sysfiles? That would tell us how the drive repaired itself.

[t...@desertdatarecovery.com]

If the SA was write blocked there should not have been any changes.

 

Tim Homer - Lead Engineer

Desert Data Recovery

t...@desertdatarecovery.com

www.desertdatarecovery.com

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/c32f0c0b-e326-45e9-8300-5f7e0cfba29cn%40googlegroups.com.

[Amarbir[CDR-Labs]]

Hello ,

      Attached is Initial Volume 3 Sysfile 348 and self corrected file

Google Drive - >  https://drive.google.com/file/d/1UsE54I5lpbcsyfQdsrFRz0ajngEt-cz6/view?usp=sharing

[Fraser Corrance]

I cant say I have ever seen a Seagate do something quite like this before. Out of curiosity, did you check the log when you parsed 348 to make sure that it auto-selected the correct version? Apparently, the utility can sometimes select the incorrect version which can cause the parsed components of the file to be incorrectly parsed. The first part of the rebuilt 348 file from the beginning up to about 0x0000D0 looks very similar to the ones I compared it to from my profiles folder. I have not found any in my profiles that look like your file from 0x000100 on though looks really strange. 

What model, firmware version, and MCMT version is the drive you are working on? If I have something really close to it I would like to compare it to it. 

Have you tried running the C>U10 command to try and rebuild the media cache? This command shouldn't wipe the data from the MCMT as far as I know. 

[$300 Data Recovery]

I only know how to use these two:

MCMT/Parser

MCMT/Edit

Parse to see if there are problems or not. If so, you Edit and check all boxes. Then re-parse to confirm it's good (I had one yesterday that after "Edit" was still bad). Then cu10.

Then upload fixed 348 it in RAM. To setup in RAM: send handshake command as usual (drive reaches Ready state) then use 'Autoinitialization' window, click to upload MCMT in RAM.

If that doesn't give sector access, then "F,,22" in terminal, Ctrl+R for Online mode, re-read Drive ID, then uploaded Translator in RAM from your made backup (in Autoinitialization window).

[t...@desertdatarecovery.com]

MCMT describes LBAs that are stored in the Media Cache.

 

U10 erases MCMT but not MC, however since U10 erases all the pointers to MC, data from MC becomes unavailable (but not erased).

 

Rebooting the drive after U10 and writing 348 back (if its not corrupt) will restore MC access.

 

Tim Homer - Lead Engineer

Desert Data Recovery

t...@desertdatarecovery.com

www.desertdatarecovery.com

 

From: datarecovery...@googlegroups.com <datarecovery...@googlegroups.com> On Behalf Of Fraser Corrance
Sent: Thursday, September 23, 2021 10:11 AM
To: DataRecoveryCertification <datarecovery...@googlegroups.com>
Subject: Re: Rosewood : Media Cache MCMT Solutions

 

I cant say I have ever seen a Seagate do something quite like this before. Out of curiosity, did you check the log when you parsed 348 to make sure that it auto-selected the correct version? Apparently, the utility can sometimes select the incorrect version which can cause the parsed components of the file to be incorrectly parsed. The first part of the rebuilt 348 file from the beginning up to about 0x0000D0 looks very similar to the ones I compared it to from my profiles folder. I have not found any in my profiles that look like your file from 0x000100 on though looks really strange. 

--

Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/a106bbad-bcd1-43e9-bbcd-a6b084c5a45an%40googlegroups.com.

[$300 Data Recovery]

"writing 348 back (if its not corrupt) will restore MC access."

In my experience, this rarely works and sometimes causes more headaches like LED issue (requiring shorting/cu10 again). This is why the 348 upload to RAM method is better IMO.

[t...@desertdatarecovery.com]

Agreed.

 

Tim Homer - Lead Engineer

Desert Data Recovery

t...@desertdatarecovery.com

www.desertdatarecovery.com

 

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/9d36e2a9-626c-41c3-8dc5-23e0bba33437n%40googlegroups.com.

[Fraser Corrance]

Makes sense. Thanks for sharing that tip. :-)

[pbzcbf...@gmail.com]

The first physical sector is unreadable. The "self corrected" MCMT appears to have been cleared rather than repaired.

I think it should be possible to repair the header (0x00 - 0xFF) and clear the first few records (0x100 - 0xFFF). You will have some data loss, though.

These are what cleared records look like (32 bytes per record):

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F

00000100  FF FF FF FF FF 02 00 00 01 00 00 00 00 00 00 00 19 27 06 00 00 FF FF FF FF FF FF 00 00 00 00 00

00000120  FF FF FF FF FF 03 00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 FF FF FF FF FF FF 00 00 00 00 00

00000140  FF FF FF FF FF 04 00 00 01 00 00 00 00 00 00 00 02 00 00 00 00 FF FF FF FF FF FF 00 00 00 00 00

00000160  FF FF FF FF FF 05 00 00 01 00 00 00 00 00 00 00 03 00 00 00 00 FF FF FF FF FF FF 00 00 00 00 00

00000180  FF FF FF FF FF 06 00 00 01 00 00 00 00 00 00 00 04 00 00 00 00 FF FF FF FF FF FF 00 00 00 00 00

000001A0  FF FF FF FF FF 07 00 00 01 00 00 00 00 00 00 00 05 00 00 00 00 FF FF FF FF FF FF 00 00 00 00 00

000001C0  FF FF FF FF FF 08 00 00 01 00 00 00 00 00 00 00 06 00 00 00 00 FF FF FF FF FF FF 00 00 00 00 00

........

00C4E360  FF FF FF FF FF 15 27 06 01 00 00 00 00 00 00 00 13 27 06 00 00 FF FF FF FF FF FF 00 00 00 00 00

00C4E380  FF FF FF FF FF 16 27 06 01 00 00 00 00 00 00 00 14 27 06 00 00 FF FF FF FF FF FF 00 00 00 00 00

00C4E3A0  FF FF FF FF FF 17 27 06 01 00 00 00 00 00 00 00 15 27 06 00 00 FF FF FF FF FF FF 00 00 00 00 00

00C4E3C0  FF FF FF FF FF 18 27 06 01 00 00 00 00 00 00 00 16 27 06 00 00 FF FF FF FF FF FF 00 00 00 00 00

00C4E3E0  FF FF FF FF FF 19 27 06 01 00 00 00 00 00 00 00 17 27 06 00 00 FF FF FF FF FF FF 00 00 00 00 00

00C4E400  FF FF FF FF FF 01 00 00 01 00 00 00 00 00 00 00 18 27 06 00 00 19 27 06 19 27 06 00 00 00 00 00

00C4E420  FF FF FF FF FF 00 00 00 01 00 40 00 00 00 00 00 00 00 00 00 00 1A 27 06 1A 27 06 00 01 00 00 00

00C4E440  FF FF FF FF FF 1B 27 06 01 00 00 00 00 00 00 00 1B 27 06 00 00 1B 27 06 1B 27 06 00 00 00 00 00

00C4E460  FF FF FF FF FF 1C 27 06 01 00 00 00 00 00 00 00 1C 27 06 00 00 1C 27 06 1C 27 06 00 00 00 00 00

00C4E480  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00C4E4A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00C4E4C0  FF FF FF FF FF 00 00 00 FF FF FF FF FF 1A 27 06 00 00 00 00 01 00 00 00 02 00 00 00 00 00 00 00

00C4E4E0  FF FF FF FF FF 00 00 00 FF FF FF FF FF 01 00 00 00 00 00 00 01 00 00 00 03 00 00 00 00 00 00 00

00C4E500  FF FF FF FF FF 00 00 00 FF FF FF FF FF 02 00 00 00 00 00 00 01 00 00 00 04 00 00 00 00 00 00 00

00C4E520  FF FF FF FF FF 00 00 00 FF FF FF FF FF 03 00 00 00 00 00 00 01 00 00 00 05 00 00 00 00 00 00 00

00C4E540  FF FF FF FF FF 00 00 00 FF FF FF FF FF 04 00 00 00 00 00 00 01 00 00 00 06 00 00 00 00 00 00 00

00C4E560  FF FF FF FF FF 00 00 00 FF FF FF FF FF 05 00 00 00 00 00 00 01 00 00 00 07 00 00 00 00 00 00 00

00C4E580  FF FF FF FF FF 00 00 00 FF FF FF FF FF 06 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00

00C4E5A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00C4E5C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Then there is a section at the end, also cleared. It consists of 0x8EA2 16-byte records.

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00E759C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00E759D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00E759E0  00 00 00 00 FF FF FF 00 00 00 00 00 00 00 00 00

00E759F0  00 00 00 00 FF FF FF 00 00 00 00 00 00 00 00 00

00E75A00  00 00 00 00 FF FF FF 00 00 00 00 00 00 00 00 00

........

00EBC3C0  00 00 00 00 FF FF FF 00 00 00 00 00 00 00 00 00

00EBC3D0  00 00 00 00 FF FF FF 00 00 00 00 00 00 00 00 00

00EBC3E0  00 00 00 00 FF FF FF 00 00 00 00 00 00 00 00 00

00EBC3F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00EBC400  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00