Date: Mon, 27 Nov 2017 13:08:40 +0000 From: Pete French <petefrench@ingresso.co.uk> To: freebsd-geom@freebsd.org Subject: GELI strangeness with gstat Message-ID: <E1eJJ9M-000FSw-GZ@dilbert.ingresso.co.uk>
next in thread | raw e-mail | index | archive | help
So, I have a set of machines running rul disc encryption with GELI. The output from gstat on an example one looks something like this: 0 27 3 100 0.4 16 100 0.1 1.1| ada0p4 0 27 3 100 0.9 16 100 0.2 1.3| ada0p4.eli I uapgraded a couple of thme to much faster CPUs - the output then started looking like this: 0 146 0 0 0.0 125 604 0.1 5.7| ada0p4 2 146 0 0 0.0 125 604 0.1 104.3| ada0p4.eli ...so the .eli device is now running at 100% despite the underlying disc only being about 6% busy. This was software encryption - my assumption was that the faster COU's were now enabling me to overload the encryption somehow, so I enabled AES-NI on the COU. Now I have hardware encryption. But the output from gstat still looks the same. Whats going on here ? Its very ouzzlking. What is even odder is that these machines are ina HAST pair, and the secondary side looks fine - i.e. only a few percent busy on the disc and the encrypted device. If I sap roles then the efect persists - the HAST primary has a massively busy ELI device. I realise the oprimary will be doing reads as well as writes, but as you can see from the snapshot above, its not singificany compares to the writes, and the effect is also ther when the load is dominated by writes. I am teoprted to think that gstat is being screwy here, but it bothers me not knowing (especially as I am trying to tarck diwn bottlenecks in the system), Anyone got any opinions on what might be showing up here ? -pete.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1eJJ9M-000FSw-GZ>