Mark Lord <kernel@xxxxxxxxxxxx> writes: > On 10-11-18 08:33 PM, Ted Ts'o wrote: >>>> >>>> Before we go gung ho on this, there's no evidence that N discontiguous >>>> ranges in one command are any better than the ranges sent N times ... >>>> the same amount of erase overhead gets sent on SSDs. >>> >>> No, we do have evidence: execution time of the TRIM commands on the SSD. >>> >>> The one-range-at-a-time is incredibly slow compared to multiple >>> ranges at a time. That slowness comes from somewhere, with about >>> 99.9% certainty that it is due to the drive performing slow flash >>> erase cycles. >> >> Mark, I think you are over-generalizing here. You have observed with >> some number of flash drives --- maybe only one, but I don't know that >> for sure --- that TRIM is slow. Even if we grant that you are correct >> in your conclusion that it is because the drive is doing slow flash >> erase cycles (and I don't completely accept that; I haven't seen your >> your measurements since we know that any kind of command that requires >> a queue drain/flush before it can execute is going to be slow, and I >> don't know what kind of _slow_ you are observing). > > I do this stuff on modest hardware: ata_piix. > There is NO QUEUE TO FLUSH. > > So one might expect TRIM to operate at the same speed as ordinary WRITEs. > But it doesn't. When I measured this in detail (and things have not changed > much since then), we were talking 10s of milliseconds to 100s of milliseconds > per TRIM command. > > The only possible explanation for that would be waiting on flash erase commands. If you guys want to test how long trims take, Lukas wrote a test program that does this. It can be found here: http://sourceforge.net/projects/test-discard/ It will even spit out nice graphs that show you b/w, average trim duration, maximum duration, etc. Some devices are better than others. We've definitely seen trims take a lot of time compared to regular I/O. However, using the batched discard ioctl in a cron job, I don't think we have to worry about this particular problem. And I don't buy the argument that users want to do this by hand. Most users want things to Just Work(TM). Cheers, Jeff -- 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
