the translator on RozewoodAF looks quite different from that on A5 or 8C. Сompare the 2B module

ok, thx, i will.

pepe

_________________
Adatmentés - Data recovery

2B cannot hold that many info, so even if it is slightly different, it has nothing to do with trim.
Also, 2B often has garbage in unused area that resembles to structured data, but it is not part of the translator. This might also account for the differences, even within family.

pepe

_________________
Adatmentés - Data recovery

pepe,
And there is not much information needed there, just one bit is enough to indicate whether there is data there or not. The point is not to force the disk to monitor partially occupied tapes, it is free - we use it immediately. You don't need to subtract it to change it. Maybe over time they will make an analysis of the translator, as on SMR WD. In the meantime, it's so crooked.

It would not be very rational to use a bitmap for the bands since trim commands work on sector level. A bitmap for all the sectors would take up 30.5MB for an 1TB disk. 2B is 1MB altogether.
So if it works like that it is surely not in 2B.

pepe

_________________
Adatmentés - Data recovery

pepe,
I do not know how they did it, maybe they mark the entire tape. He would not give zeros according to logic, but data according to physics. So TRIM somehow works.

Lots of this is beyond me - If the data is visible on a physical rather than a logical level and PC3K utility is reading it in that way why was there a speed increase within pc3K utility after rebuilding the translator. I can understand why DE reads data rather than 00 but can't figure out what's going on within the utility and how it interacts with the translator. Am I missing some information/research which has been posted before?

_________________
Data Recovery Services in the UK.
https://www.usbrecovery.co.uk/

I don't have PC3000 so can't help you there, but perhaps this: https://blog.acelaboratory.com/wd-smr-d ... maged.html

_________________
Joep - http://www.disktuna.com - video & photo repair & recovery service

I know wd translator pretty well, built sw to parse it and use it for example to build head map before PC3k had this option, so that's an open book for me (more or less).
To RW AF i am only saying that 2B has nothing to do with it most probably, according to my logic. So it must be somewhere else.
I will check when i have some time, which i don't, at the moment.
It is also against any logic that after rebuilding the translator the data would become visible, as that's precisely the case when everything should be trimmed instead. So it sounds pretty odd to me. (I am not questioning your experiences of course, just thinking)
- what happens if you write back orig 2B?
- 3_348?
- other modules?

pepe

_________________
Adatmentés - Data recovery

How is it regenerating a working translator which doesn't appear to be fragmented to the point of being useless?
Is data actually ever actually being trimmed?

_________________
Data Recovery Services in the UK.
https://www.usbrecovery.co.uk/

No, data is not 'trimmed', just unmapped.
i did not really understand your first Q.
pepe

_________________
Adatmentés - Data recovery

I can confirm that. On Seagate regenerate translator with NRGList "untrim" lost data.
After regenerate, data can be read at full speed and aren't fragmented. It's possible
to recover data with directory structure and names. Probably on Seagate trimmed data
map is separated from translator. Regenerate translator command clear that map....

Trimming on seagate can mean 2 things from write perspective:
- no need to commit trimmed records from MC
- Committed areas can be overwritten in the main data area.
From read perspective the drive can simply return 00 data for trimmed LBA ranges.

- Trim records are stored in MCMT.
- Data is completely inaccessible if MCMT is corrupt.
- translator regen clears MC and MCMT
this last thing is why you get LBA access but i doubt you eventually tested if you got back previously trimmed data, the story is about accessing user data that wasn't accessible due to corrupt MCMT.
So, in fact, it is unneccessary to regen translator, clearing MCMT is sufficient.

On the other hand, clearing MC is not a wise thing to do - thus tr regen is a bad habit - coz you may need the data from it...

pepe

_________________
Adatmentés - Data recovery

Thank You for info.
I will check U10 on that drive.

Mr. Pepe was right.
Clear MCMT untrim data. Translator regeneration is unnecessary risk.

This can be interesting in forensic cases....

Thx for the confirmation,

pepe

_________________
Adatmentés - Data recovery

Hello,

I am currently having the same case (rosewood, SMR, format...)

I have a problem with the recover data from the ST2000LM007 disk.
The disk is from September 15, 2019 - so it's probably an SMR disk.
The disk is OK - the case is related to logical problems and SA.

The client started formatting this disk by mistake (NTFS).
According to his account - he quickly realized that he was formatting the wrong disk and quickly pulled out the power plug. It reportedly lasted a few seconds.

Currently - the situation is as follows:
We have almost the entire structure visible (although some few data have disappeared from the structure), but most of the data does not open (files filled with 00).
Question :
Is it possible to recovery data and get at least part of the data? If so, is it also possible to try to recover data that is not currently visible in $mft?


I reported the above problem to TS in ACE.
The answer I got is as follows:

"...There is only one Translator on Seagate drives.
Launch Quick then Full disk analysis (at set the reading to UDMA)
DE will scan whole user area and try to build virtual partition based on all available valid metadata.
Result of this be the best possible with FS structure...."

I'm going to scan the drive.
According to the above tips...

But...
At the same time - I have a question for forum members who know about this topic:
Do you think that scanning data in DE (via UDMA) will allow to read the data ?
Is this really the "best result" ?

Regards
Igen

you might need to manually analyze the FS and find out why the addressing went bad. It is possible that some data was in MC and drive got trimmed, which might result in 00 reading if the data was in MC. Perhaps removing trim records from MCMT restores these...

pepe

_________________
Adatmentés - Data recovery

Thanks Pepe.

One question:
Will using the CU10 command and rewriting SysFile 348 (from the copy) improve the situation?

Thanks for answer..

Igen

can't see how it would...

_________________
Adatmentés - Data recovery