Re: mfi driver performance too bad on LSI MegaRAID SAS 9260-8i
> On 22 Jun 2016, at 04:08, Jason Zhang wrote: > > Mark, > > Thanks > > We have same RAID setting both on FreeBSD and CentOS including cache setting. > In FreeBSD, I enabled the write cache but the performance is the same. > > We don’t use ZFS or UFS, and test the performance on the RAW GEOM disk > “mfidx” exported by mfi driver. We observed the “gstat” result and found > that the write latency > is too high. When we “dd" the disk with 8k, it is lower than 1ms, but it is > 6ms on 64kb write. It seems that each single write operation is very slow. > But I don’t know > whether it is a driver problem or not. There is an option you can use (I do it all the time!) to make the card behave as a plain HBA so that the disks are handled by the “da” driver. Add this to /boot/loader.conf hw.mfi.allow_cam_disk_passthrough=1 mfip_load=“YES" And do the tests accessing the disks as “da”. To avoid confusions, it’s better to make sure the disks are not part of a “jbod” or logical volume configuration. Borja. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD as iSCSI target and VMWare ESX
On 0621T0835, Eugene M. Zheganin wrote: > Hi. > > Guys, does someone have experience with multiple LUNs on a target in > ctld ? Recently I was installing ESX on a bunch of diskless hosts, > connected to FreeBSD ctld. I was organizing them inside one target, > multiple LUNs. As soon as the _count_ of LUNS went over 9, the whole > thing went crazy - ESX were unable to install, showing multiple errors > and not showing more than 10 LUNs from FreeBSD (and they were 11), and > even the last one created was unsuitable for installation. As soon as I > placed these "extra" LUNs inside the separate targets and LUN 0, > everything went back to normal. I understand completely this sounds like > a bad dream. I checked the VMWare limitations > (https://www.vmware.com/pdf/vsphere5/r55/vsphere-55-configuration-maximums.pdf) > > - seems like it's supporting 256 LUNs per server. I've also checked > their "iSCSI Best Practices Guide" and nowhere is says "use one LUN from > a target". It's not fair to suspect FreeBSD from the start, but this ML > is a much more frendlier place (at least I feel it to be so) - so, does > anyone have experience providing more than 9 LUNs from a target ? > Because I don't - prior to this I was providing one LUN from each > target, and it seems that I will continue to do so. Do you see anything in the system logs, on either the ESX or FreeBSD side? ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: stable/10 release.sh fails during mkisoimages-uefi.sh
On Wed, Apr 27, 2016 at 5:37 PM, Slawa Olhovchenkov wrote: > On Wed, Apr 27, 2016 at 01:00:19PM -0400, Rick Miller wrote: > > > Hi all, > > > > Building stable/10@r298482 errors when executing newfs_msdos on > > uefi-disc1.iso as shown below. It is being built on a system running a > > 10.2 version of stable/10. I believe this problem could be due to either > > the attempt to compile newer stable/10 code on an older 10.2 version of > > stable/10 or something in the code is broke. Can you shed some light on > > the error below? > > This issuse (makefs: error: The Disk Label must be at most 32 > characters long) present always. > Best way is fix makefs to shrink label to 32 characters and conver > this error to warning Thanks. This is resolved with this patch: diff --git a/release/amd64/mkisoimages-uefi.sh b/release/amd64/mkisoimages-uefi.sh index 9526ad7..0441dac 100644 --- a/release/amd64/mkisoimages-uefi.sh +++ b/release/amd64/mkisoimages-uefi.sh @@ -50,7 +50,7 @@ if [ $# -lt 3 ]; then exit 1 fi -LABEL=`echo $1 | tr '[:lower:]' '[:upper:]'`; shift +LABEL=`echo $1 | tr '[:lower:]' '[:upper:]' | cut -c 1-32`; shift NAME=$1; shift publisher="The FreeBSD Project. http://www.FreeBSD.org/"; and PR 210463 was opened. -- Take care Rick Miller ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
i386 build failure
What is wrong? ===> usr.bin/clang/clang (all) /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangbasic/libclangbasic.a(Targets.o):(.rodata+0x75a8): undefined reference to `.Lsunkaddr375' /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangbasic/libclangbasic.a(Targets.o):(.rodata+0x75bc): undefined reference to `.Lsunkaddr375' /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangbasic/libclangbasic.a(Targets.o):(.rodata+0x75d0): undefined reference to `.Lsunkaddr375' /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangbasic/libclangbasic.a(Targets.o):(.rodata+0x75e4): undefined reference to `.Lsunkaddr375' /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangbasic/libclangbasic.a(Targets.o):(.rodata+0x75f8): undefined reference to `.Lsunkaddr375' /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangbasic/libclangbasic.a(Targets.o):(.rodata+0x760c): more undefined references to `.Lsunkaddr375' follow c++: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. make[5]: stopped in /usr/src/usr.bin/clang/clang *** Error code 1 Stop. make[4]: stopped in /usr/src/usr.bin/clang *** Error code 1 Stop. make[3]: stopped in /usr/src/usr.bin *** Error code 1 Stop. make[2]: stopped in /usr/src *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
