lkml.org 
[lkml]   [2009]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Discard support (was Re: [PATCH] swap: send callback when swap slot is freed)
    On Thu, 13 Aug 2009, Greg Freemyer wrote:

    > On Thu, Aug 13, 2009 at 12:33 PM, <david@lang.hm> wrote:
    >> On Thu, 13 Aug 2009, Markus Trippelsdorf wrote:
    >>
    >>> On Thu, Aug 13, 2009 at 08:13:12AM -0700, Matthew Wilcox wrote:
    >>>>
    >>>> I am planning a complete overhaul of the discard work.  Users can send
    >>>> down discard requests as frequently as they like.  The block layer will
    >>>> cache them, and invalidate them if writes come through.  Periodically,
    >>>> the block layer will send down a TRIM or an UNMAP (depending on the
    >>>> underlying device) and get rid of the blocks that have remained unwanted
    >>>> in the interim.
    >>>
    >>> That is a very good idea. I've tested your original TRIM implementation on
    >>> my Vertex yesterday and it was awful ;-). The SSD needs hundreds of
    >>> milliseconds to digest a single TRIM command. And since your
    >>> implementation
    >>> sends a TRIM for each extent of each deleted file, the whole system is
    >>> unusable after a short while.
    >>> An optimal solution would be to consolidate the discard requests, bundle
    >>> them and send them to the drive as infrequent as possible.
    >>
    >> or queue them up and send them when the drive is idle (you would need to
    >> keep track to make sure the space isn't re-used)
    >>
    >> as an example, if you would consider spinning down a drive you don't hurt
    >> performance by sending accumulated trim commands.
    >>
    >> David Lang
    >
    > An alternate approach is the block layer maintain its own bitmap of
    > used unused sectors / blocks. Unmap commands from the filesystem just
    > cause the bitmap to be updated. No other effect.

    how does the block layer know what blocks are unused by the filesystem?

    or would it be a case of the filesystem generating discard/trim requests
    to the block layer so that it can maintain it's bitmap, and then the block
    layer generating the requests to the drive below it?

    David Lang

    > (Big unknown: Where will the bitmap live between reboots? Require DM
    > volumes so we can have a dedicated bitmap volume in the mix to store
    > the bitmap to? Maybe on mount, the filesystem has to be scanned to
    > initially populate the bitmap? Other options?)
    >
    > Assuming we have a persistent bitmap in place, have a background
    > scanner that kicks in when the cpu / disk is idle. It just
    > continuously scans the bitmap looking for contiguous blocks of unused
    > sectors. Each time it finds one, it sends the largest possible unmap
    > down the block stack and eventually to the device.
    >
    > When normal cpu / disk activity kicks in, this process goes to sleep.
    >
    > That way much of the smarts are concentrated in the block layer, not
    > in the filesystem code. And it is being done when the disk is
    > otherwise idle, so you don't have the ncq interference.
    >
    > Even laptop users should have enough idle cpu available to manage
    > this. Enterprise would get the large discards it wants, and
    > unmentioned in the previous discussion, mdraid gets the large discards
    > it also wants.
    >
    > ie. If a mdraid raid5/raid6 volume is built of SSDs, it will only be
    > able to discard a full stripe at a time. Otherwise the P=D1 ^ D2 logic
    > is lost.
    >
    > Another benefit of the above is the code should be extremely safe and testable.
    >
    > Greg
    >
    \
     
     \ /
      Last update: 2009-08-13 22:47    [W:4.218 / U:0.744 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site