Question about extents.c/ext4_ext_punch_hole
Dear all,
I'm reading the code of extents.c, and confused by the function "ext4_ext_punch_hole".
In my understanding, if we want to punch hole for the range (loff_t offset, loff_t length), then we finally will get one hole block-size aligned, right?
[code in ext4_ext_punch_hole]
first_block = (offset + sb->s_blocksize - 1) >> EXT4_BLOCK_SIZE_BITS(sb); stop_block = (offset + length) >> EXT4_BLOCK_SIZE_BITS(sb);
[code]
Quoted 1 line
From the code, we'll get one hole range contained in the range [offset, length+offset-1].
For example, we set the block size to 1K, and we specify the range [offset:1000, offset:2000]. Then we'll get first_block:1,stop_block:2, with some head/tail range ignored.
{-23------|===========|----952---}
1000 1024 2048 2999
offset offset+length-1'==='means punched hole here.
Please correct me if I'm wrong.
Regards,
Quoted 27 lines · Wang Sheng-Hui
Date: Sun, 15 Jul 2012 21:03:42 +0800
From: Wang Sheng-Hui <[email protected]>
To: Allison Henderson <[email protected]>,
Lukas Czerner <[email protected]>, Theodore Ts'o <[email protected]>, [email protected]
Subject: Question about extents.c/ext4_ext_punch_holeDear all,
I'm reading the code of
extents.c, and confused by the function "ext4_ext_punch_hole".In my understanding, if we want to punch hole for the range (
loff_toffset,loff_tlength), then we finally will get one hole block-size aligned, right?[code in
ext4_ext_punch_hole]first_block = (offset + sb->s_blocksize - 1) >> EXT4_BLOCK_SIZE_BITS(sb); stop_block = (offset + length) >> EXT4_BLOCK_SIZE_BITS(sb);[code]
From the code, we'll get one hole range contained in the range [offset, length+offset-1].
For example, we set the block size to 1K, and we specify the range [offset:1000, offset:2000]. Then we'll get first_block:1,stop_block:2, with some head/tail range ignored.
{-23------|===========|----952---} 1000 1024 2048 2999 offset offset+length-1
Quoted 6 lines
'==='means punched hole here.
Please correct me if I'm wrong.
Regards,
Hi,
your understanding is partially right. Indeed we're going to align the range to the block size, but that's because blocks in this range are going to be freed. Then, the rest of the range (non block aligned) is going to be zeroed manually. The reason is that we can not free those blocks, because it still contains valid data and we can not just leave it alone, since after the punch hole finishes we'll have to read zeroes from entire punched region.
Btw, there is a patch set on the list which reworks part of the punch hole code patch, it starts with the path:
[PATCH 01/12 v2] Revert "ext4: remove no longer used functions in inode.c"
I hope that helps.
-Lukas
Quoted 8 lines · Lukáš Czerner
Indeed we're going to align
the range to the block size, but that's because blocks in this range are going to be freed. Then, the rest of the range (non block aligned) is going to be zeroed manually. The reason is that we can not free those blocks, because it still contains valid data and we can not just leave it alone, since after the punch hole finishes we'll have to read zeroes from entire punched region.
Got it. Thanks, Lukas!
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html