I may be misreading the fio code, but it looks like there is an issue with generation of the offset to ttrim if trim_backlog option is not set. In this case, get_io_u falls through the check_get_trim (which starts with the check if td->flags has TD_F_TRIM_BACKLOG set and immediately returns if not), and the call chain is then set_io_u_file->fill_io_u->set_rw_dir->get_rw_dir where, in the last else clause of the conditional, ddir is set to DDIR_TRIM. Subsequently, the get_next_offset then - say, in the random I/O case - ends up in the __get_next_rand_offset returning a random offset not necessarily written to previously. TRIMming an unwritten space is not necessarily a bug (although some SSD controllers may have different view), but is hardly the operation fio intended to perform. The very next portion of the __get_next_rand_offset, dealing with the random map, could have solved the issue (if it's real), with the write logic reversed for TRIM (return if the offset is busy and look up the next busy offset otherwise). For this to work, o_randommap should be made required for trim jobs without o_trim_backlog set. Regards, Andrey -- To unsubscribe from this list: send the line "unsubscribe fio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
