Date: Tue, 14 Dec 2021 13:55:51 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 258204] [geli] Extremely poor performance copying directory with lot of small files on nvme Message-ID: <bug-258204-227-3lNJHo6SD5@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-258204-227@https.bugs.freebsd.org/bugzilla/> References: <bug-258204-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258204 --- Comment #19 from Eugene Grosbein <eugen@freebsd.org> --- (In reply to Ali Abdallah from comment #16) I've checked aesni(4) sources and it changed its type from "hardware" in 12= .x and earlier to "accelerated software" in 13, so it is OK. If you want to speedup GELI further, you may decrease its overhead: 1) Use command like "nvmecontrol identify nvme0ns1" to see if your NVMe namespace uses 512 byte-sized blocks or 4096 byte-sized. In former case, use command like "nvmecontrol format -f 1 nvme0ns1" to reformat the namespace f= or 4K "sectors" (all data will be lost for that namespace). 2) Use "geli init -s 8192 -l 128" to create ELI volume with 8K "sectors" and AES-XTS-128. 3) Use newfs -b 65536 -f 8192 to create UFS with biggest supported block/fragment sizes. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-258204-227-3lNJHo6SD5>