Re: Discard support (was Re: [PATCH] swap: send callback when swap slot is freed)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 16/08/2009 20:29, Alan Cox wrote:
trim is mostly for ssd's though, and those tend to not have the "goes
for a hike" behavior as much......

Bench one.

I wonder if it's worse to batch stuff up, because then the trim itself
gets bigger and might take longer.....

They seem to implement a sort of async single threaded trim, which can
only have one outstanding trim at a time.

I'm slightly out of my depth here, but: if a single TRIM is issued, which apparently returns quickly, can one then revert to issuing ordinary commands like reads and writes and have them complete as quickly as they normally do, or does any following command have to wait until the trim completes? This could be useful if it turned out we won't stall these devices as long as we don't issue more than one TRIM every few seconds; we could keep a TRIM coalesce queue down to being (say) 5 seconds long (or at least, a configurable small number of seconds).

Cheers,

John.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux