Hello friends

I'm trying to realize what follow, thank you for any hint.

Premise, in my example I'm talking about an 1TB hdd. 1TB hdd is made of 1.953.525.168 LBAs or 512 bytes sectors.

The goal: when checking the hard drive content with HEX editor, the bigger is the drive, the more sensible is vertical scroll bar. In few words, if you move the mouse of 1/10 of mm, the LBAs will scroll for so many hundreds of thousands LBAs/sectors. So it is really hard to determinate the exact position where "something happen".

This is the practical example I'm talking about.

Roughly, with hex editor I see that from sector/LBA 1.350.429.000 on, the drive up to the end (1.953.525.167) is blank

While from sector/LBA 1.279.000.000 down to LBA 0 , the sectors are occupied.

I need to seek the exact position where from blank content it turns to occupied content.

So it should be matter of reading sectors (hopefully in a fast manner, maybe blocks of many sectors at once) and compare their content with HEX value 00.
Ideally this should work with the provided offsets so
from 1.350.429.000 in reverse, down to 1.279.000.000

As soon any non x00 is found, that is the sector I'm seeking for.

I suppose this can be scripted with dd and some other command line tool.

Can you kindly hint or provide the solution

Thank you

Cor

blank (non-occupied) does not mean that is filled up with hex 00. Those areas may contain "random" bytes.

Hi there,

what you describe is obvious, but exactly what one would expect. If you look at the drive on a sector-by-sector level, you have to take the entire capacity into account, because you're working "below" the file system and any information it would provide.

For what reason, actually? Bear in mind that sectors with non-zero contents aren't necessarily allocated: If you store huge files and them delete them again some day, the actual contents of the sectors once occupied by that file remains unchanged. There'll just be an entry in some file system structure indicating that these sectors are free now and can be reused. Plus, space on the file system isn't necessarily allocated contiguously. There's fragmentation - all file systems that allow deleting and rewriting files are subject to fragmentation. Some more, some less.

However, if you assume that there is a point where all sectors with lower numbers contain non-zero data and all sectors "behind" contain all zeroes, this point can be found easily and very efficiently. The algorithm is called binary search and works like that:

1. Assume the transition is at 50%. Convert that into a sector number.
2. Read the sector number you got so far.
3. If it is blank, the transition is in the lower half; if it's non-blank, it is in the upper half.
4. Recalculate the sector number so that it indicates the middle of the portion you found out until now.
5. Go back to step 2, unless the range of sectors is 1.

That way, you only have to read 31 sectors on a 1TB drive to find the transition - precisely, it's the 2-based logarithm of the total number of sectors.

But again: I think your effort here is pointless, and I can't actually see a purpose.

[X] Doc CPU

I did a practice problem like that in Python. While I did the practice a while ago doesn't mean I can remember it now. Someone with python memory could make a script that could do what you want.

@ DOC-CPU: thank you for your considerations. As stated in my initial post, I'll give/provide a rough offset in both directions: "rough end of written area (forward)" (non-blank), and "rough end of blank area (reverse) (blank). Rough because if it were siple to seek the turning point with just the HEX editor scroll bar... I would not have been here asking for this help :-)))))). An micro-move of the scroll bar, results in so many hundreds thousands sectors' jump and just pressing the page up/down will take minutes to scroll some just hundreds of sectors.
In the reality, provided the two offsets, the seek can be linear. From the offset "rough end of blank area" in reverse, down to "rough end of written area"

@very one of you friends:

thank you for your replies

About the blank area, it is definitely blank, x00 filled. Though, I was asking to compare with x00, eventually, the blank area I want to skip, could/will be filled with the same value, so instead than x00 it will be compared the value that I'll read in the HEX editor

As stated in my original post, bear in mind that I start from an HEX editor view and check, which shows blank (x00) filled sectors (in reverse) from the last LBA down to a certain one, where the the hdd written the last LBA.

The script I'd like to get hints on, will seek for that turning point (reverse) from blank to non blank (or from any xYZ filled value to a non-xYZ one)

Thank you for your effort and thank you for any further hint.