Fix EXT4 extent offset double-counting causing block address overflow

[Ronitsabhaya75]

Closes#441

current behavior:

EXT4 filesystem corruption occurs when creating large files in containers, causing block addresses to exceed maximum inode values. This results in errors like:

EXT4-fs warning (device vdb): ext4_block_to_path:105: block 1710731624 > max in inode 21209237

The fix:

Remove the pre-added offset. Connect to the correct block address immediately by passing blocks.start directly, allowing offset to be applied once inside fillExtents. This ensures block addresses remain within filesystem bounds for files of any size.

[dcantah]

@Ronitsabhaya75 This does look wrong, but do you actually see this fixes these warnings? I remember trialing a very similar fix a week or so ago and didn't seem like much changed. I haven't had much time to dig back in

[Ronitsabhaya75]

@dcantah I haven't been able to test it yet because I'm on macOS 15.6 and the project requires macOS 26+.

However, I'm confident this is the root cause based on the math:

The bug: Line 1137 passes start: blocks.start + offset, then line 1053 adds offset again:

extentStart =(blocks.start + offset)+(offset + i * MaxBlocksPerExtent)= blocks.start +2*offset +...

For extent block iteration 5231: offset = 856,842,240

Double-counted: extentStart = 1,713,685,480 (matches the 1,710,731,624 error!)

Filesystem max: 134,217,728 blocks (way exceeded!)

[dcantah]

The math I agree with, I just vaguely remember still seeing these warnings even with a similar (possibly the exact same) fix. I'll give it a whirl

[Ronitsabhaya75]

The math I agree with, I just vaguely remember still seeing these warnings even with a similar (possibly the exact same) fix. I'll give it a whirl

for sure Um we can test it and check if there are warnings i can have deeper look into it. thank you @dcantah for reviewing

[jglogan]

@Ronitsabhaya75 I tried the following

• Cloned your repo at 6811c56 which has the fix.
• In my container project I ran swift package edit --path your-containerization-path containerization
• make all install ; container system stop ; container system start
• container system property set image.init vminit.latest
• Ensured no pre-existing filerace volume, and ran the stress-ng test.

I'm still seeing warning messages like:

% container exec stress-filerace dmesg
Warning! Running debug build. Performance may be degraded.
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x610f0000]
[ 0.000000] Linux version 6.14.9 (root@4c158802-47be-4992-a00c-a0f3da44bbae) (gcc (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #1 SMP Thu Oct 9 08:43:53 UTC 2025
[ 0.000000] KASLR enabled
[ 0.000000] efi: UEFI not found.
...
[ 12.428930] pps pps0: PPS event at 1767315002.783812547
[ 12.428941] pps pps0: capture assert seq #12
[ 12.908559] EXT4-fs warning (device vdc): ext4_block_to_path:105: block 1485723486 > max in inode 1210
[ 13.331390] EXT4-fs warning (device vdc): ext4_block_to_path:105: block 1687149417 > max in inode 2009
[ 13.456962] pps pps0: PPS event at 1767315003.811846506
[ 13.456966] pps pps0: capture assert seq #13
[ 14.481002] pps pps0: PPS event at 1767315004.835884673
[ 14.481011] pps pps0: capture assert seq #14
[ 14.889429] EXT4-fs warning (device vdc): ext4_block_to_path:105: block 1673136487 > max in inode 1741
[ 15.010187] EXT4-fs warning (device vdc): ext4_block_to_path:105: block 1796465330 > max in inode 1938
[ 15.010334] EXT4-fs warning (device vdc): ext4_block_to_path:105: block 2078962099 > max in inode 1938
[ 15.149213] EXT4-fs warning (device vdc): ext4_block_to_path:105: block 1171790081 > max in inode 1531
[ 15.432046] EXT4-fs warning (device vdc): ext4_block_to_path:105: block 1545724136 > max in inode 2009
[ 15.504919] pps pps0: PPS event at 1767315005.859802298
[ 15.504923] pps pps0: capture assert seq #15
[ 16.528919] pps pps0: PPS event at 1767315006.883801924
[ 16.528924] pps pps0: capture assert seq #16
[ 17.548922] pps pps0: PPS event at 1767315007.903805091
[ 17.548926] pps pps0: capture assert seq #17

[Ronitsabhaya75]

• n my container project

so I think there is different issue I'll have deeoper look into it thank you for testing it out @jglogan

[Ronitsabhaya75]

@jglogan if this didnt work i was thinking:

The problem is in how fillExtents calculates the physical block address (extentStart).
extentStart is meant to be the physical block address on disk, but we're adding extentBlock (a logical file offset that can be huge for large files) to start.

For example, in a large file:

start = 100,000
extentBlock = 2,078,962,099 (logical offset in file)
extentStart = 2,079,062,099

do you think this would be another problem for the issue?