Date: Thu, 05 Mar 2015 16:16:26 +0100 From: Robert Schulze <rs@bytecamp.net> To: freebsd-geom@freebsd.org Subject: Re: Trim on gmirrored SSDs is slow and results in inresponsive system Message-ID: <54F8734A.40409@bytecamp.net> In-Reply-To: <54F86A06.4090301@multiplay.co.uk> References: <54F6FE2E.60303@bytecamp.net> <54F707CC.6070105@multiplay.co.uk> <54F7147F.8070206@bytecamp.net> <54F718D9.1080201@multiplay.co.uk> <54F721BC.5070204@bytecamp.net> <54F72E39.2070105@multiplay.co.uk> <54F863C9.3070002@bytecamp.net> <54F86A06.4090301@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, > These values look totally reasonable in terms a d/s. > > How does this compare to the none gmirror case? Its barely measurable, but in this case I can start a loop directly after unlink with very small interval. The only measurement with non-null values is: dT: 0.205s w: 0.200s filter: ada L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ada0 0 51537 5 156 2.4 0 0 0.0 51532 1649018 3.8 18.2 ada1 thats all. It takes not even half a second to push the DELETE ops to the SSD in case of non-gmirrored UFS. Again, with a 2 GB file. > Compile a version of the kernel with this change reverted. > > Details of the change can be seen here. > https://svnweb.freebsd.org/base?view=revision&revision=268816 done, but it did not change behaviour. regards, Robert Schulze -- /7\ bytecamp GmbH Geschwister-Scholl-Str. 10, 14776 Brandenburg a.d. Havel HRB15752, Amtsgericht Potsdam, Geschaeftsfuehrer: Bjoern Barnekow, Frank Rosenbaum, Sirko Zidlewitz tel +49 3381 79637-0 werktags 10-12,13-17 Uhr, fax +49 3381 79637-20 mail rs@bytecamp.net, web http://bytecamp.net/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54F8734A.40409>