On 3/6/22 21:45, Ritesh Harjani wrote:
Just FYI - The change which we discussed to fix the max_block to max_end_block, is not correct. Since it will still leave 1 block at the end after punch operation, if the file has s_bitmap_maxbytes size. This is due to the fact that, "end" is expected to be 1 block after the end of last block. Will try look into it to see how can we fix this. 1210 /** 1211 * ext4_ind_remove_space - remove space from the range 1212 * @handle: JBD handle for this transaction 1213 * @inode: inode we are dealing with 1214 * @start: First block to remove 1215 * @end: One block after the last block to remove (exclusive) 1216 * 1217 * Free the blocks in the defined range (end is exclusive endpoint of 1218 * range). This is used by ext4_punch_hole(). 1219 */ 1220 int ext4_ind_remove_space(handle_t *handle, struct inode *inode, 1221 ext4_lblk_t start, ext4_lblk_t end) -ritesh
Hi Ritesh, I tried to bisect it and went as far back as 4.4 and the issue still triggers there. I couldn't build anything older than that with my compiler, but I suspect that the issue exists even before 3.0 where ext4_fallocate() has been introduced. -- Thanks, Tadeusz
