Messages in this thread | | | Date | Thu, 18 Nov 2010 19:34:30 -0500 | From | Mark Lord <> | Subject | Re: [PATCH 1/2] fs: Do not dispatch FITRIM through separate super_operation |
| |
On 10-11-18 06:52 PM, Martin K. Petersen wrote: >>>>>> "Mark" == Mark Lord<kernel@teksavvy.com> 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???
| |