On 20/04/10 05:21 PM, Greg Freemyer wrote:
Mark, This is the patch implementing the new discard logic.
..
Signed-off-by: Lukas Czerner <lczerner@xxxxxxxxxx>
..
+void ext4_trim_extent(struct super_block *sb, int start, int count, + ext4_group_t group, struct ext4_buddy *e4b) +{ + ext4_fsblk_t discard_block; + struct ext4_super_block *es = EXT4_SB(sb)->s_es; + struct ext4_free_extent ex; + + assert_spin_locked(ext4_group_lock_ptr(sb, group)); + + ex.fe_start = start; + ex.fe_group = group; + ex.fe_len = count; + + mb_mark_used(e4b,&ex); + ext4_unlock_group(sb, group); + + discard_block = (ext4_fsblk_t)group * + EXT4_BLOCKS_PER_GROUP(sb) + + start + + le32_to_cpu(es->s_first_data_block); + trace_ext4_discard_blocks(sb, + (unsigned long long)discard_block, + count); + sb_issue_discard(sb, discard_block, count); + + ext4_lock_group(sb, group); + mb_free_blocks(NULL, e4b, start, ex.fe_len); +}Mark, unless I'm missing something, sb_issue_discard() above is going to trigger a trim command for just the one range. I thought the benchmarks you did showed that a collection of ranges needed to be built, then a single trim command invoked that trimmed that group of ranges.
.. Mmm.. If that's what it is doing, then this patch set would be a complete disaster. It would take *hours* to do the initial TRIM. Lukas ? -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
