Trim on gmirrored SSDs is slow and results in inresponsive system

[Robert Schulze]

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 at bytecamp.net, web http://bytecamp.net/