zfs recv hangs in kmem arena

[Alan Cox]

On Tue, Oct 21, 2014 at 5:03 PM, Alan Cox <alan.l.cox at gmail.com> wrote:

> On Sun, Oct 19, 2014 at 10:30 AM, James R. Van Artsdalen <
> james-freebsd-fs2 at jrv.org> wrote:
>
>> Removing kern.maxfiles from loader.conf still hangs in "kmem arena".
>>
>> I tried using a memstick image of -CURRENT made from the release/
>> process and this also hangs in "kmem arena"
>>
>> An uninvolved server of mine hung Friday night in state"kmem arena"
>> during periodic's "zpool history".  After a reboot it did not hang
>> Saturday night.
>>
>>
>
>
> How up to date is your source tree?  r2720221 is relevant.  Without that
> change, there are circumstances in which the code that is supposed to free
> space from the kmem arena doesn't get called.
>
>
That should be r272071.


>
>
>
>> On 10/16/2014 11:37 PM, James R. Van Artsdalen wrote:
>> > On 10/16/2014 11:10 PM, Xin Li wrote:
>> >> On 10/16/14 8:43 PM, James R. Van Artsdalen wrote:
>> >>> On 10/16/2014 11:12 AM, Xin Li wrote:
>> >>>>> On 9/26/2014 1:42 AM, James R. Van Artsdalen wrote:
>> >>>>>> FreeBSD BLACKIE.housenet.jrv 10.1-BETA2 FreeBSD 10.1-BETA2
>> >>>>>> #2 r272070M: Wed Sep 24 17:36:56 CDT 2014
>> >>>>>> james at BLACKIE.housenet.jrv:/usr/obj/usr/src/sys/GENERIC
>> >>>>>> amd64
>> >>>>>>
>> >>>>>> With current STABLE10 I am unable to replicate a ZFS pool
>> >>>>>> using zfs send/recv without zfs hanging in state "kmem
>> >>>>>> arena", within the first 4TB or so (of a 23TB Pool).
>> >>>> What does procstat -kk 1176 (or the PID of your 'zfs' process
>> >>>> that stuck in that state) say?
>> >>>>
>> >>>> Cheers,
>> >>>>
>> >>> SUPERTEX:/root# ps -lp 866 UID PID PPID CPU PRI NI   VSZ   RSS
>> >>> MWCHAN   STAT TT      TIME COMMAND 0 866  863   0  52  0 66800
>> >>> 29716 kmem are D+    1  57:40.82 zfs recv -duvF BIGTOX
>> >>> SUPERTEX:/root# procstat -kk 866 PID    TID COMM             TDNAME
>> >>> KSTACK 866 101573 zfs              -                mi_switch+0xe1
>> >>> sleepq_wait+0x3a _cv_wait+0x16d vmem_xalloc+0x568 vmem_alloc+0x3d
>> >>> kmem_malloc+0x33 keg_alloc_slab+0xcd keg_fetch_slab+0x151
>> >>> zone_fetch_slab+0x7e zone_import+0x40 uma_zalloc_arg+0x34e
>> >>> arc_get_data_buf+0x31a arc_buf_alloc+0xaa dmu_buf_will_fill+0x169
>> >>> dmu_write+0xfc dmu_recv_stream+0xd40 zfs_ioc_recv+0x94e
>> >>> zfsdev_ioctl+0x5ca
>> >> Do you have any special tuning in your /boot/loader.conf?
>> >>
>> >> Cheers,
>> >>
>> > Below.  I had forgotten some of this was there.
>> >
>> > After sending the previous message I ran kgdb to see if I could get a
>> > backtrace with function args.  I didn't see how to do it for this proc,
>> > but during all this the process un-blocked and started running again.
>> >
>> > The process blocked again in kmem arena after a few minutes.
>> >
>> >
>> > SUPERTEX:/root# cat /boot/loader.conf
>> > zfs_load="YES"           # ZFS
>> > vfs.root.mountfrom="zfs:SUPERTEX/UNIX"        # Specify root partition
>> > in a way the
>> >                 # kernel understands
>> > kern.maxfiles="32K"        # Set the sys. wide open files limit
>> > kern.ktrace.request_pool="512"
>> > #vfs.zfs.debug=1
>> > vfs.zfs.check_hostid=0
>> >
>> > loader_logo="beastie"        # Desired logo: fbsdbw, beastiebw, beastie,
>> > none
>> > boot_verbose="YES"        # -v: Causes extra debugging information to be
>> > printed
>> > geom_mirror_load="YES"        # RAID1 disk driver (see gmirror(8))
>> > geom_label_load="YES"        # File system labels (see glabel(8))
>> > ahci_load="YES"
>> > siis_load="YES"
>> > mvs_load="YES"
>> > coretemp_load="YES"        # Intel Core CPU temperature monitor
>> > #console="comconsole"
>> > kern.msgbufsize="131072"    # Set size of kernel message buffer
>> >
>> > kern.geom.label.gpt.enable=0
>> > kern.geom.label.gptid.enable=0
>> > kern.geom.label.disk_ident.enable=0
>> > SUPERTEX:/root#
>> >
>>
>> _______________________________________________
>> freebsd-current at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org
>> "
>>
>
>