Hello,
I'm trying to setup a new geli disk and i'm seeing what looks like a
memory leak.
After initializing the device i've tried to do the dd command from
/dev/random
like this one:
dd if=/dev/random of=/dev/da0p1.eli bs=1m
And i can see that wired memory is increasing and never released, using about 1
GB after
500 GB transferred.
The HD is a Seagate ST2000DL 003 with 4k sectors. My geli configuration is:
magic: GEOM::ELI
version: 5
ealgo: AES-XTS
keylen: 128
aalgo: HMAC/SHA256
provsize: 2000397868544
sectorsize: 4096
gpt partitions:
Geom name: da0
state: OK
fwheads: 255
fwsectors: 63
last: 3907029134
first: 34
entries: 128
scheme: GPT
Providers:
1. Name: da0p1
Mediasize: 2000397868544 (1.8T)
Sectorsize: 512
Mode: r1w1e2
rawuuid: 661ae84d-55a7-11e0-88d5-0013a9f69377
rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b
label: backup
length: 2000397868544
offset: 1048576
type: freebsd-ufs
index: 1
end: 3907029134
start: 2048
Consumers:
1. Name: da0
Mediasize: 2000398934016 (1.8T)
Sectorsize: 512
Mode: r1w1e3
Device is connected over USB2 just in case the memory leak is in USB code
instead of geli.
My FreeBSD version is:
8.2-RC1 amd64
vmstat -m output:
Type InUse MemUse HighUse Requests Size(s)
kqueue 10 9K - 45 256,512,2048
proc-args 52 4K - 16500 16,32,64,128,256
ithread 70 12K - 70 32,128,256
CAM dev queue 5 1K - 5 128
KTRACE 100 13K - 100 128
linker 275 411K - 336 16,32,64,128,256,512,1024,2048,4096
lockf 26 3K - 102 64,128
entropy 1024 64K - 1024 64
ip6ndp 6 1K - 6 64,128
temp 34 587K - 513343 16,32,64,128,256,512,1024,2048,4096
devbuf 3953 5385K - 10690 16,32,64,128,256,512,1024,2048,4096
cache 1 1K - 1 32
module 426 54K - 426 128
mtx_pool 2 16K - 2
osd 2 1K - 2 16,64
subproc 217 403K - 6562 512,4096
proc 2 16K - 2
session 29 4K - 339 128
pgrp 38 5K - 407 128
cred 74 12K - 57324 64,256
uidinfo 7 3K - 295 128,2048
plimit 14 4K - 4233 256
CAM queue 19 1K - 59 16,32
CAM SIM 5 2K - 5 256
sysctltmp 0 0K - 1680 16,32,64,128,256,4096
sysctloid 4218 208K - 4325 16,32,64,128
sysctl 0 0K - 314942 16,32,64
callout 1 512K - 1
umtx 198 25K - 198 128
p1003.1b 1 1K - 1 16
SWAP 2 549K - 2 64
scsi_da 0 0K - 21 16
bus-sc 83 280K - 3198 16,32,64,128,256,512,1024,2048,4096
bus 1211 104K - 6294 16,32,64,128,256,512,1024
devstat 12 25K - 12 32,4096
eventhandler 83 7K - 83 64,128
scsi_cd 0 0K - 3 16
kobj 300 1200K - 368 4096
Per-cpu 1 1K - 1 32
CAM periph 8 2K - 21 16,32,64,128,256
CAM XPT 47 23K - 85433 32,64,128,256,2048
rman 170 21K - 607 16,32,128
ata_generic 2 2K - 2 1024
sbuf 0 0K - 3430 16,32,64,128,256,512,1024,2048,4096
stack 0 0K - 2 256
taskqueue 17 2K - 17 16,32,128
Unitno 11 1K - 59 32,64
iov 0 0K - 14434 16,32,64,128,256,512
select 51 7K - 51 128
ioctlops 0 0K - 231551 16,32,64,128,256,512,1024,2048,4096
msg 4 30K - 4 2048,4096
sem 4 11K - 4 512,1024
shm 1 20K - 1
tty 22 22K - 25 1024,2048
pts 3 1K - 4 256
mbuf_tag 0 0K - 10 32
ksem 1 8K - 1
shmfd 1 8K - 1
USBdev 122 51K - 830 64,128,512,1024,4096
pcb 18 157K - 42 16,32,128,1024,2048,4096
soname 25 3K - 2811 16,32,64,128
biobuf 1 2K - 8 2048
vfscache 1 1024K - 1
vfs_hash 1 512K - 1
vnodes 2 1K - 2 256
USB 115 184K - 129 16,32,64,128,256,512,2048,4096
vnodemarker 0 0K - 26007 512
mount 137 7K - 305 16,32,64,128,256
BPF 9 10K - 9 128,512,4096
ether_multi 15 1K - 22 16,32,64
ifaddr 264 21K - 265 32,64,128,256,512,4096
ifnet 6 11K - 6 128,2048
ad_driver 1 1K - 1 32
clone 6 24K - 6 4096
arpcom 2 1K - 2 16
fw_com 1 1K - 1 64
lltable 14 6K - 16 256,512
ar_driver 0 0K - 6 512,2048
acd_driver 1 2K - 1 2048
athdev 3 66K - 3 2048
acpidev 67 5K - 67 64
kbdmux 7 10K - 7 16,512,1024,2048,4096
routetbl 24 524K - 124 32,64,128,256,512
80211com 1 8K - 1
80211node 1 1K - 1 1024
80211scan 1 4K - 1 4096
igmp 5 2K - 5 256
in_multi 2 1K - 3 256
sctp_iter 0 0K - 3 256
sctp_ifn 2 1K - 2 128
sctp_ifa 4 1K - 4 128
sctp_vrf 1 1K - 1 64
sctp_a_it 0 0K - 3 16
hostcache 1 28K - 1
syncache 1 96K - 1
ath_hal 3 18K - 4 2048
DEVFS1 140 70K - 149 512
DEVFS3 162 41K - 172 256
in6_multi 12 2K - 12 32,256
mld 5 1K - 5 128
NFS FHA 1 2K - 1 2048
rpc 2 9K - 2 256
audit_evclass 172 6K - 211 32
savedino 0 0K - 136 256
dirrem 0 0K - 866 64
mkdir 0 0K - 16 64
diradd 0 0K - 859 64
freefile 0 0K - 172 64
freeblks 0 0K - 159 256
freefrag 0 0K - 9 64
allocindir 0 0K - 7550 128
indirdep 0 0K - 2282 64
allocdirect 0 0K - 214 256
bmsafemap 0 0K - 1864 128
newblk 1 1K - 7765 64,512
inodedep 1 512K - 1031 256
pagedep 1 128K - 142 128
ufs_dirhash 78 18K - 78 16,32,64,128,256,512
ufs_mount 19 60K - 34 128,256,512,1024,2048,4096
UMAHash 1 1K - 2 512,1024
DEVFS 26 1K - 27 16,128
DEVFSP 3 1K - 711 64
vm_pgdata 2 129K - 2 128
pfs_nodes 70 18K - 70 256
pfs_vncache 1 1K - 1 64
GEOM 145 33K - 847 16,32,64,128,256,512,1024,2048,4096
io_apic 1 2K - 1 2048
memdesc 1 4K - 8 32,4096
pci_link 16 2K - 16 64,128
atkbddev 2 1K - 2 64
acpi_perf 2 1K - 2 128
acpica 1858 184K - 345598 16,32,64,128,256,512,1024,2048
acpipwr 1 1K - 1 64
acpitask 1 2K - 1 2048
isadev 8 1K - 8 128
fw_xfer 0 0K - 1 256
firewire 11 35K - 14 64,128,512,1024,2048,4096
cdev 9 3K - 9 256
acpisem 62 8K - 62 128
sigio 2 1K - 2 64
filedesc 84 43K - 6435 512,1024
kenv 72 11K - 76 16,32,64,128
msi 1 1K - 1 128
nexusdev 4 1K - 4 16
mixer 2 8K - 2 4096
feeder 15 2K - 18 32,128
hdac 10 15K - 10 64,128,256,512,1024,2048
ata_cam 2 2K - 56884 64,256,1024
fdesc_mount 1 1K - 1 16
linux 13 1K - 13 64
crypto 12 4K - 14 64,128,256,512,1024
eli data 4 266K - 3912142 64,256,1024
If you need more information the disk is not in production so i can
try whatever is needed.
Thanks a lot.
Regards.
--
La prueba m?s fehaciente de que existe vida inteligente en otros
planetas, es que no han intentado contactar con nosotros.
On Sat, Mar 26, 2011 at 01:33:48AM +0100, Victor Balada Diaz wrote:> Hello, > > I'm trying to setup a new geli disk and i'm seeing what looks like a memory leak. > After initializing the device i've tried to do the dd command from /dev/random > like this one: > > dd if=/dev/random of=/dev/da0p1.eli bs=1m >Hello again, I've found the cause of the memory leak and i attach a patch to fix it. I hope the patch is good enough to get committed or at least helps someone made a better patch and commit it. Patched file is src/sys/geom/eli/g_eli.c The problem happens when you're using data integrity verification and you need to write more than MAXPHYS. If you look at g_eli_integrity.c:314 you'll see that geli creates a second request to write all that's needed. Each of the request get the callback to g_eli_write_done once they're done. The first request will get up to g_eli.c:209 and find that there are still requests pending so instead of calling g_io_deliver to notify it's written data, it just returns and waits until all requests are done to say everything's OK. The problem is that once you return, you're leaking this g_bio. You can see with vmstat -z how g_bio increases and never releases memory. I just destroy the current bio before returning and that prevents the memory leak. Regards. Victor. -- La prueba m?s fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. -------------- next part -------------- A non-text attachment was scrubbed... Name: g_eli.c.patch Type: text/x-diff Size: 407 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20110401/b94c3f74/g_eli.c.bin