Date: Thu, 19 Mar 2015 16:02:21 +0200 From: Alexander Motin <mav@FreeBSD.org> To: Emil Muratov <gpm@hotplug.ru>, freebsd-fs@freebsd.org Subject: Re: CAM Target over FC and UNMAP problem Message-ID: <550AD6ED.50201@FreeBSD.org> In-Reply-To: <550979C8.2070603@hotplug.ru> References: <54F88DEA.2070301@hotplug.ru> <54F8AB96.6080600@FreeBSD.org> <54F9782A.90501@hotplug.ru> <54F98135.5000908@FreeBSD.org> <550979C8.2070603@hotplug.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi. On 18.03.2015 15:12, Emil Muratov wrote: > I've made some progress with this issue using iSCSI transport and > sniffing initiator/target command-responses traffic. > I found that initiator sends request VPD 0xb0 page and than UNMAP > command with long LBA range and then timeouts while waiting response. > That was interesting, ctladm option 'ublocksize' doesn't make any > difference, so I've tried to tackle other values. > I'm not sure how this should work in the first place but I found if not > a solution for ZFS than at least a workaround for CTL. > I looked through ctl code and changed hardcoded values for 'unmap LBA > count' and 'unmap block descr count' to 8Mb and 128. > With this values UNMAP works like a charm! No more IO blocks, IO > timeouts, log error, high disk loads or anything, only a medium > performance drop-down during even very large unmaps. But this > performance drop is nothing compared with those all-blocking issues. No > problems over FiberChannel transport too. In my present understanding of SBC-4 specification, implemented also in FreeBSD initiator, MAXIMUM UNMAP LBA COUNT is measured not per segment, but per command. From such perspective limiting it to 8MB per UNMAP command is IMHO an overkill. Could you try to increase it to 2097152, which is 1GB, while decrease MAXIMUM UNMAP BLOCK DESCRIPTOR COUNT from 128 to 64? Will it give acceptable results? -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?550AD6ED.50201>