Skip to content

Conversation

@pfeigl
Copy link

@pfeigl pfeigl commented Nov 18, 2025

As stated in the documentation Inodes are packed into the metadata blocks, and are not aligned to block boundaries, therefore inodes overlap compressed blocks it is possible, that metadata blocks are not within the data block.

The code in general accounts for this situation. However the distance calculation worked with incorrect assumptions in regards to this.

This leads to situations, where for example directory metadata blocks could not be calculated correctly, when the metadata spans across multiple data blocks.

While debugging the problem, I added two very minimal changes to make things a little more clear in other areas.

These are the two different documentations which I used while debugging and fixing the problem:

As stated in the documentation `Inodes are packed into the metadata blocks, and are not aligned to block boundaries, therefore inodes overlap compressed blocks` it is possible, that metadata blocks are not within the data block.

The code in general accounts for this situation. However the distance calculation worked with incorrect assumptions in regards to this.

This leads to situations, where for example directory metadata blocks could not be calculated correctly, when the metadata spans across multiple data blocks.
@pfeigl
Copy link
Author

pfeigl commented Nov 18, 2025

Small additional comment on the implementation. While the iteration and continously reading the blocks seems expensive, the following always is true:

  • If everything is within one block, no other blocks are read
  • If block boundaries are already crossed while reading the metadata, the block is already cached in the background
  • If at all, most of the time only a single boundary is crossed
  • The only exception would probably be, if there is a single folder structure with enough directories or files, so that the metadata block for this information spans across 8kb

@LTRData LTRData merged commit 5199b95 into LTRData:LTRData.DiscUtils-initial Nov 18, 2025
1 check passed
@LTRData
Copy link
Owner

LTRData commented Nov 18, 2025

Thanks a lot for your contribution!

@pfeigl
Copy link
Author

pfeigl commented Nov 18, 2025

Wow, this was fast, thanks!

Short question: In which cycles do you typically release new versions? As you can imagine, we are currently blocked by the issue with a specific image we have floating around here :-)

Thanks for keeping the wonderful library so up-to-date!

@LTRData
Copy link
Owner

LTRData commented Nov 18, 2025

I understand! There are a few important fixes in the pipe that has been a bit delayed because I have found a couple of side effects that needed to get solved first. But I am pretty close now to a new release to Nuget and if all goes well it will happen within a few hours now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants