On Thu, Nov 18, 2010 at 4:34 PM, Mark Lord <kernel@xxxxxxxxxxxx> wrote: > On 10-11-18 06:52 PM, Martin K. Petersen wrote: >>>>>>> >>>>>>> "Mark" == Mark Lord<kernel@xxxxxxxxxxxx> writes: >> >> Mark> If FITRIM is still issuing single-range-at-a-time TRIMs, then I'd >> Mark> call that a BUG that needs fixing. Doing TRIM like that causes >> Mark> tons of unnecessary ERASE cycles, shortening the SSD lifetime. It >> Mark> really needs to batch them into groups of (up to) 64 ranges at a >> Mark> time (64 ranges fits into a single 512-byte parameter block). >> >> We don't support coalescing discontiguous requests into one command. But >> we will issue contiguous TRIM requests as big as the payload can >> handle. That's just short of two gigs per command given a 512-byte >> block. >> >> I spent quite a bit of time trying to make coalescing work in the >> spring. It got very big and unwieldy. When we discussed it at the >> filesystem summit the consensus was that it was too intrusive to the I/O >> stack, elevators, etc. > > Surely if a userspace tool and shell-script can accomplish this, > totally lacking real filesystem knowledge, then we should be able > to approximate it in kernel space? > > This is FITRIM we're talking about, not the on-the-fly automatic TRIM. > > FITRIM could perhaps use a similar approach to what wiper.sh does: > reserve a large number of free blocks, and issue coalesced TRIM(s) on them. > > The difference being, it could walk through the filesystem, > trimming in sections, rather than trying to reserve/trim the entire > freespace all in one go. > > Over-thinking it??? Martin, I agree with Mark. When you say "make coalescing work" it sounds like major overkill. FITRIM should be able to lock a group of non-contiguous free ranges, send them down to the block layer as a single pre-coalesced set, and the block layer just needs to pass it on in a synchronous way. Then when that group of ranges is discarded, FITRIM releases the locks. Every TRIM causes a cache flush anyway on the SSD, so the synchronous aspect of the process should not be a problem. (Maybe SCSI with thin provisioning would see a performance hit?) To my small brain, the only really complex part is sending something like that into MDraid, because that one set of ranges might explode into thousands of ranges and then have to be coalesced back down to a more manageable number of ranges. ie. with a simple raid 0, each range will need to be broken into a bunch of stride sized ranges, then the contiguous strides on each spindle coalesced back into larger ranges. But if MDraid can handle discards now with one range, it should not be that hard to teach it handle a group of ranges. Greg -- Greg Freemyer Head of EDD Tape Extraction and Processing team Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer CNN/TruTV Aired Forensic Imaging Demo - http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retrieved/ The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
