DragonFly BSD
DragonFly users List (threaded) for 2010-02
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Update on tmpfs and swapcache work (in master)

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Sat, 20 Feb 2010 12:53:22 -0800 (PST)

    I've nailed a few more bugs in tmpfs, including one that caused
    excessive paging to swap, a VM object leaking in kernel virtual memory
    (try to imagine that visually <grin>), and stomped a few bug reports
    related to fsstress tests Venkatesh ran.

    tmpfs is now working very nicely with memory & swap, with minimal
    paging to swap when memory is available to hold the data.  It is
    starting to look like it will be a very good fit against SSD-based
    swap and swapcache, and frankly tmpfs should work well with HD-based
    swap too.


    swapcache is also faring very well in all tests done so far, for
    those people interested inconfiguring Solid State Drive (SSD) based
    swap space.  The manual page has been updated and the data caching
    capability has gotten a little more sophisticated with the new
    chflags flags.

    Some tuning with disklabel64 (for labeling the SSDs) has been done to
    align the partition base and reduce write amplification and write
    combining effects by the SSD drive firmware.  Swapcache also does a
    pretty good job clustering and linearizing write operations.

    I am running ongoing tests on pkgbox64 with one of these Intel X25-V
    40G SSDs with 32G of swapcache configured and so far I haven't even
    managed to tick over the wear meter.  It started at 99% and it's
    still 99% after 569GB worth of intentionally heavy write activity.

    The X25-V has a stated write durability of around 40TB but with
    static wear leveling MLC cells theoretically have a 10,000 erase
    cycle endurance which would be more around 400TB.  The Intel SSD
    apparently does a combination of static and dynamic wear leveling.
    A key point here is the swapcache is laying down data very efficiently
    compared to what a filesystem-on-SSD would do, and this should result
    in significantly less write amplification than we would otherwise expect.

    My expectation is we could get upwards of 150-250TB of write durability
    out of this particular device.  I won't know for probably another week
    or two at the rate pkgbox64 is currently writing but if it turns out to
    be true then MLC-based SSDs will be totally viable at higher write

					Matthew Dillon 

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