lkml.org 
[lkml]   [2010]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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???


    \
     
     \ /
      Last update: 2010-11-19 01:37    [W:3.000 / U:0.232 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site