I'm using geli, gmultipath, and ZFS on a large system, with hundreds of
drives. What I'm seeing is that under at least some workloads, the overall
performance is limited by the single geom kernel process. procstat and
kgdb aren't much help in telling exactly why this process is using so much
CPU,
n,
>
> why do you think it will hurt single-threaded performance?
>
> --
> Paweł Jakub Dawidek
>
>
>
> > On Jul 3, 2020, at 12:30, Alan Somers wrote:
> >
> > I'm using geli, gmultipath, and ZFS on a large system, with hundreds of
> > drives. Wh
dek wrote:
> Direct dispatch would be great for geli, especially that geli can use own
> (multiple) threads when necessary (eg. using crypto cards). With AES-NI you
> could go straight to the disk.
>
> --
> Paweł Jakub Dawidek
>
>
>
> > On Jul 3, 2020, at 13:22, Alan Somers
are crypto accelerator to test it on. Could anybody help me out with
that?
https://reviews.freebsd.org/D25587
On Sat, Jul 4, 2020 at 5:16 PM John-Mark Gurney wrote:
> Alan Somers wrote this message on Sat, Jul 04, 2020 at 15:59 -0600:
> > I might give this a shot. What is the best way
Most modern SES backplanes have two LEDs per hard disk. There's a
"fault" LED and a "locate" LED. You can control either one with
sesutil(8) or, with a little more work, sg_ses from
sysutils/sg3_utils. They're very handy for tasks like replacing a
failed disk, especially in large enclosures. Ho
