vnop_strategy unexpectedly zero-extends files
On implementing vnop_mmap, vnop_strategy and other related VNOPs as suggested in https://developer.apple.com/forums/thread/756358, my vnop_strategy routine ends up zero-extending files.
The end result is shown below.
Original file:
% hexdump -Cs 0x012085a0 progit.pdf
012085a0 30 30 20 6e 20 0a 74 72 61 69 6c 65 72 0a 3c 3c |00 n .trailer.<<|
012085b0 20 2f 53 69 7a 65 20 33 35 30 39 0a 2f 52 6f 6f | /Size 3509./Roo|
012085c0 74 20 32 20 30 20 52 0a 2f 49 6e 66 6f 20 31 20 |t 2 0 R./Info 1 |
012085d0 30 20 52 0a 3e 3e 0a 73 74 61 72 74 78 72 65 66 |0 R.>>.startxref|
012085e0 0a 31 38 38 33 38 33 39 30 0a 25 25 45 4f 46 0a |.18838390.%%EOF.|
012085f0
New file:
% hexdump -Cs 0x012085a0 /Volumes/myfs/progit_cp.pdf
012085a0 30 30 20 6e 20 0a 74 72 61 69 6c 65 72 0a 3c 3c |00 n .trailer.<<|
012085b0 20 2f 53 69 7a 65 20 33 35 30 39 0a 2f 52 6f 6f | /Size 3509./Roo|
012085c0 74 20 32 20 30 20 52 0a 2f 49 6e 66 6f 20 31 20 |t 2 0 R./Info 1 |
012085d0 30 20 52 0a 3e 3e 0a 73 74 61 72 74 78 72 65 66 |0 R.>>.startxref|
012085e0 0a 31 38 38 33 38 33 39 30 0a 25 25 45 4f 46 0a |.18838390.%%EOF.|
012085f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
0120c000
The size of the original file is 0x012085f0 or 18908656 in decimal.
The size of the new file is 0x0120c000 or 18923520 in decimal.
The difference between the two files is 14864 bytes, which is filled with zeros.
The blocks of code in my vnop_write that set IO_HEADZEROFILL and IO_TAILZEROFILL are never entered into.
The last cluster_write call is passed a uio whose offset is 18874368 and resid is 34288:
2024-07-24 11:34:05 vnops.c:497 myfs_vnop_write: uio_offset(uio): 18874368 uio_resid(uio): 34288
2024-07-24 11:34:05 vnops.c:498 myfs_vnop_write: -> cluster_write(vp, uio, originalEOF: 18874368, newEOF: 18908656, zero_head_off: 0, zero_tail_off: 18908656, lflag: 0x100001)
2024-07-24 11:34:05 vnops.c:500 myfs_vnop_write: <- cluster_write -> 0
The last vnop_strategy call is handed down a buf_count of 49152 bytes however, which is then used to create a new uio which is passed to myfs_write routine:
2024-07-24 11:34:05 vnops.c:670 myfs_vnop_strategy: uio_offset(uio): 18874368 uio_resid(uio): 49152
2024-07-24 11:34:05 vnops.c:671 myfs_vnop_strategy: -> myfs_write
2024-07-24 11:34:05 vnops.c:673 myfs_vnop_strategy: <- myfs_write -> 49152
The difference between 49152 and 34288 of 14864 bytes is what ends up being zero-extended.
dtrace(1)'ing the operation revealed the following sequence of calls being made.
About half-way through into its operation, cluster_write calls my vnop_strategy:
4 -> cluster_write proc: cp -> cluster_write(vp: progit_cp.pdf, uio, originalEOF: 8388608, newEOF: 8912896, zero_head_off: 0, zero_tail_off: 8912896, lflag: 0x100001)
4 -> myfs_vnop_strategy proc: cp file: progit_cp.pdf b_bufsize: 0 b_bcount: 65536 b_resid: 0
kernel.release.t8101`0xfffffe0014bfb610+0xcec
kernel.release.t8101`0xfffffe0014bff2f0+0x300
kernel.release.t8101`0xfffffe0014c00bd0+0x54c
kernel.release.t8101`0xfffffe0014bfd898+0x724
kernel.release.t8101`cluster_write_ext+0x2a4
kernel.release.t8101`cluster_write+0x1c
myfs`myfs_vnop_write+0xb18
kernel.release.t8101`VNOP_WRITE+0x84
It then picks it up where it left off:
4 -> cluster_write proc: cp -> cluster_write(vp: progit_cp.pdf, uio, originalEOF: 8912896, newEOF: 9437184, zero_head_off: 0, zero_tail_off: 9437184, lflag: 0x100001)
And eventually makes the final cluster_write call:
4 -> cluster_write proc: cp -> cluster_write(vp: progit_cp.pdf, uio, originalEOF: 18874368, newEOF: 18908656, zero_head_off: 0, zero_tail_off: 18908656, lflag: 0x100001)
Which is followed by another series of vnop_strategy calls:
4 -> myfs_vnop_strategy proc: cp file: progit_cp.pdf b_bufsize: 0 b_bcount: 65536 b_resid: 0
kernel.release.t8101`0xfffffe0014bfb610+0xcec
kernel.release.t8101`0xfffffe0014bff2f0+0x300
kernel.release.t8101`0xfffffe0014c00bd0+0x54c
kernel.release.t8101`0xfffffe0014bfd898+0x724
kernel.release.t8101`cluster_write_ext+0x2a4
kernel.release.t8101`cluster_write+0x1c
myfs`myfs_vnop_write+0xb18
kernel.release.t8101`VNOP_WRITE+0x84
dtrace(1)'ing the same operation on smbfs shows a different sequence of calls.
cluster_write runs start through finish:
4 -> cluster_write proc: cp -> cluster_write(vp: progit_cp.pdf, uio, originalEOF: 0, newEOF: 524288, zero_head_off: 0, zero_tail_off: 524288, lflag: 0x100001)
...
4 -> cluster_write proc: cp -> cluster_write(vp: progit_cp.pdf, uio, originalEOF: 18874368, newEOF: 18908656, zero_head_off: 0, zero_tail_off: 18908656, lflag: 0x100001)
smbfs`smbfs_vnop_write+0x354
With vnop_strategy invoked through the cluster_push path when the file gets closed:
2 -> smbfs_vnop_strategy proc: cp file: progit_cp.pdf b_bufsize: 0 b_bcount: 8388608 b_resid: 0
kernel.release.t8101`0xfffffe0026cdb610+0xcec
kernel.release.t8101`0xfffffe0026cdf2f0+0x300
kernel.release.t8101`cluster_push_err+0x2e0
smbfs`smbfs_vnop_close+0x204
I don't understand why my filesystem behaves as described above.
Perusing the source code of both the relevant parts of Darwin/XNU and SMBClient did not clarify things for me.
A nudge in the right direction would be greatly appreciated.
