Severe file system corruption 300 GB SAS case

[fzabkar]

Have you tried reading LBA 1 on its own? I'm wondering if the first sector returned by a read command is always aligned correctly.

[WebClaw]

Read drive backwards; look for asci values via hex. R-Studio can do this for you. Anything? Search for drive SN; or partial SN. I suspect there is another drive at play here despite what the client says…

[terminator2]

Read drive backwards; look for asci values via hex. R-Studio can do this for you. Anything? Search for drive SN; or partial SN. I suspect there is another drive at play here despite what the client says…

Yes your guess is absolutely right ,from the beginning I was wondering how server is configured on a single drive ,there must be at least 2 drives (Raid 1)
Customer always don't tell true story.

[terminator2]

Read drive backwards; look for asci values via hex. R-Studio can do this for you. Anything? Search for drive SN; or partial SN. I suspect there is another drive at play here despite what the client says…

Though I could not find S/N but yes in hex readable data is found , but it is random and not like normal file system data.

[WebClaw]

Get the controller; see what it says. Sounds like you have a stale RAID member.

[Arch Stanton]

Explain how 8 bytes are dropped and we immediately see next sector after, being caused by RAID. Are you suggesting the missing 8 bytes are on a different drive?

S/N? What S/N specifically?

Seems to me you're on a wild goose chase.

[WebClaw]

Just saying foundation is missing. The controller should at least confirm current setup - pre failure. Knowing that should help point him in the right direction. Not not like he has anything to gain with the current findings.

Further knowing the RAID controller would at least let us know it’s capabilities. It’s not going to be LSI that’s for sure.

SN of HDD; some controllers will write records in last sectors in clear text - DELL PERC (LSI), Intel (LSI), etc. if a SN is found it may include the SN of additional R members (even historical devices).

[Arch Stanton]

FWIW NTFS BS in UFS screenshot says sector size 512. The boot sector @ 2048 actually says 504. I assume this value is written at time of file system creation (format).

..

[fzabkar]

FWIW NTFS BS in UFS screenshot says sector size 512. The boot sector @ 2048 actually says 504.

Where are you seeing this? I downloaded those 10,000 sectors again and I'm still seeing 512 bytes per sector at LBA 2048. :-????

Code:

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

00100000  EB 58 90 4D 53 44 4F 53 35 2E 30 00 02 04 DE 19  ëX.MSDOS5.0...Þ.
00100010  02 00 00 00 00 F8 00 00 3F 00 FF 00 00 08 00 00  .....ø..?.ÿ.....
00100020  00 40 06 00 11 03 00 00 00 00 00 00 02 00 00 00  .@..............
00100030  01 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00100040  80 01 29 2B 61 F5 26 4E 4F 20 4E 41 4D 45 20 20  €.)+aõ&NO NAME 
00100050  20 20 46 41 54 33 32 20 20 20 33 C9 8E D1 BC F4    FAT32   3ɎѼô

Even more confusing is that LBA 1 in the OP's first posting is correctly aligned, while in the subsequent 10,000 sector dump it is misaligned.

https://forum.hddguru.com/download/file.php?id=22848&mode=view (correctly aligned)

Incorrectly aligned ...

Code:

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

000001F0  00 00 00 00 00 00 55 AA 45 46 49 20 50 41 52 54  ......UªEFI PART

[Arch Stanton]

Oh you're right! DOH! I edited it yesterday or some, way past bed-time. And today when I opened it forgot about it. Sorry, false alert.

[Arch Stanton]

FWIW NTFS BS in UFS screenshot says sector size 512. The boot sector @ 2048 actually says 504.

Where are you seeing this? I downloaded those 10,000 sectors again and I'm still seeing 512 bytes per sector at LBA 2048. ???

Code:

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

00100000  EB 58 90 4D 53 44 4F 53 35 2E 30 00 02 04 DE 19  ëX.MSDOS5.0...Þ.
00100010  02 00 00 00 00 F8 00 00 3F 00 FF 00 00 08 00 00  .....ø..?.ÿ.....
00100020  00 40 06 00 11 03 00 00 00 00 00 00 02 00 00 00  .@..............
00100030  01 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00100040  80 01 29 2B 61 F5 26 4E 4F 20 4E 41 4D 45 20 20  €.)+aõ&NO NAME 
00100050  20 20 46 41 54 33 32 20 20 20 33 C9 8E D1 BC F4    FAT32   3ɎѼô

Even more confusing is that LBA 1 in the OP's first posting is correctly aligned, while in the subsequent 10,000 sector dump it is misaligned.

https://forum.hddguru.com/download/file.php?id=22848&mode=view (correctly aligned)

Incorrectly aligned ...

Code:

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

000001F0  00 00 00 00 00 00 55 AA 45 46 49 20 50 41 52 54  ......UªEFI PART

Indeed, 55 AA not properly aligned but next sector is. Weird.

[fzabkar]

I suspect that if you read one sector at a time, then each sector will be correctly aligned. However, if you read a block of sectors, then the offsets and dropped bytes accumulate throughout the block.

[fzabkar]

@terminator2, can you send a SCSI READ CAPACITY(16) command to your drive? The drive should then return its capacity in LBAs and it logical sector size.

https://linux.die.net/man/8/sg_readcap