Re: Resizing a zpool as a VMware ESXi guest ...
On 11/27/2015 12:08 PM, Matthew Grooms wrote: On 11/27/2015 3:16 AM, Willem Jan Withagen wrote: On 27-11-2015 06:59, Matthew Grooms wrote: All, I know this is a very late follow up, but spent some more time looking at this today and found some additional information that I found quite interesting. I setup two VMs, one that acts as an iSCSI initiator ( CURRENT ) and another that acts as a target ( 10.2-RELEASE ). Both are running under ESXi v5.5. There are two block devices on the initiator, da1 and da2, that I used for resize testing ... [root@iscsi-i /home/mgrooms]# camcontrol devlist at scbus1 target 0 lun 0 (cd0,pass0) at scbus2 target 0 lun 0 (pass1,da0) at scbus2 target 1 lun 0 (pass2,da1) at scbus3 target 0 lun 0 (da2,pass3) The da1 device is a virtual disk hanging off of a VMware virtual SAS controller ... [root@iscsi-i /home/mgrooms]# pciconf ... mpt0@pci0:3:0:0:class=0x010700 card=0x197615ad chip=0x00541000 rev=0x01 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = 'SAS1068 PCI-X Fusion-MPT SAS' class = mass storage subclass = SAS [root@iscsi-i /home/mgrooms]# camcontrol readcap da1 -h Device Size: 10 G, Block Length: 512 bytes [root@iscsi-i /home/mgrooms]# gpart show da1 => 40 20971440 da1 GPT (10G) 40 209714401 freebsd-ufs (10G) The da2 device is an iSCSI LUN mounted from my FreeBSD 10.2 VM running ctld ... [root@iscsi-i /home/mgrooms]# iscsictl Target name Target portalState iqn.2015-01.lab.shrew:target0iscsi-t.shrew.lab Connected: da2 [root@iscsi-i /home/mgrooms]# camcontrol readcap da2 -h Device Size: 10 G, Block Length: 512 bytes [root@iscsi-i /home/mgrooms]# gpart show da2 => 40 20971440 da2 GPT (10G) 4024 - free - (12K) 64 209713921 freebsd-ufs (10G) 2097145624 - free - (12K) When I increased the size of da1 ( the VMDK ) and then re-ran 'camcontrol readcap' without a reboot, it clearly showed that the disk size had increased. However, geom failed to recognize the additional capacity ... [root@iscsi-i /home/mgrooms]# camcontrol readcap da1 -h Device Size: 16 G, Block Length: 512 bytes [root@iscsi-i /home/mgrooms]# gpart show da1 => 40 20971440 da1 GPT (10G) 40 209714401 freebsd-ufs (10G) Here is the interesting bit. I increased the size of da2 by modifying the lun size in ctld.conf on the target and then issued a /etc/rd.d/ctld reload. When I re-ran 'camcontrol readcap' on the initiator without a reboot, it also showed that the disk size had increased, but this time geom recognized the additional capacity as well ... [root@iscsi-i /home/mgrooms]# camcontrol readcap da2 -h Device Size: 16 G, Block Length: 512 bytes [root@iscsi-i /home/mgrooms]# gpart show da2 => 40 33554352 da2 GPT (16G) 4024 - free - (12K) 64 209713921 freebsd-ufs (10G) 20971456 12582936 - free - (6.0G) I was then able to resize the partition and then grow the UFS filesystem, all without rebooting the VM ... [root@iscsi-i /home/mgrooms]# gpart resize -i 1 da2 da2p1 resized [root@iscsi-i /home/mgrooms]# gpart show da2 => 40 33554352 da2 GPT (16G) 4024 - free - (12K) 64 335543041 freebsd-ufs (16G) 3355436824 - free - (12K) [root@iscsi-i /home/mgrooms]# growfs da2p1 Device is mounted read-write; resizing will result in temporary write suspension for /var/data2. It's strongly recommended to make a backup before growing the file system. OK to grow filesystem on /dev/da2p1, mounted on /var/data2, from 10GB to 16GB? [Yes/No] Yes super-block backups (for fsck_ffs -b #) at: 21798272, 23080512, 24362752, 25644992, 26927232, 28209472, 29491712, 30773952, 32056192, 8432 [root@iscsi-i /home/mgrooms]# df -h FilesystemSizeUsed Avail Capacity Mounted on /dev/da0p3 15G1.2G 12G 9%/ devfs 1.0K1.0K 0B 100%/dev /dev/da1p19.7G 32M8.9G 0%/var/data1 /dev/da2p1 15G 32M 14G 0%/var/data2 It's also worth noting that the additional space was not recognized by gpart/geom on the initiator until after the 'camcontrol readcap da2' command was run. In other words, I'm skeptical that it was a Unit Attention notification that made the right thing happen since it still took manual prodding of cam to get the new disk geometry up into the geom layer. I remember doing this for a bhyve VM, and had the type same problem. Getting gpart in the VM to actually pickup the new size required some extra prodding (I like that word) or rebooting the VM. I can remember reporting this: tpoic: "resampeling of a ZVOL that has been resized" and getting a fix from Andrey V. Elsukov... Index: head/sys/geom/part/g_part_gpt.c
Re: Resizing a zpool as a VMware ESXi guest ...
On 11/27/2015 3:16 AM, Willem Jan Withagen wrote: On 27-11-2015 06:59, Matthew Grooms wrote: On 10/16/2014 3:10 AM, Edward Tomasz Napierała wrote: On 1010T1529, Matthew Grooms wrote: All, I am a long time user and advocate of FreeBSD and manage a several deployments of FreeBSD in a few data centers. Now that these environments are almost always virtual, it would make sense that FreeBSD support for basic features such as dynamic disk resizing. It looks like most of the parts are intended to work. Kudos to the FreeBSD foundation for seeing the need and sponsoring dynamic increase of online UFS filesystems via growfs. Unfortunately, it would appear that there are still problems in this area, such as ... a) cam/geom recognizing when a drive's size has increased b) zpool recognizing when a gpt partition size has increased For example, if I do an install of FreeBSD 10 on VMware using ZFS, I see the following ... root@zpool-test:~ # gpart show => 34 16777149 da0 GPT (8.0G) 34 10241 freebsd-boot (512K) 1058 41943042 freebsd-swap (2.0G) 4195362 125818213 freebsd-zfs (6.0G) If I increase the VM disk size using VMware to 16G and rescan using camcontrol, this is what I see ... "camcontrol rescan" does not force fetching the updated disk size. AFAIK there is no way to do that. However, this should happen automatically, if the "other side" properly sends proper Unit Attention after resizing. No idea why this doesn't happen with VMWare. Reboot obviously clears things up. [..] Now I want the claim the additional 14 gigs of space for my zpool ... root@zpool-test:~ # zpool status pool: zroot state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 gptid/352086bd-50b5-11e4-95b8-0050569b2a04 ONLINE 0 0 0 root@zpool-test:~ # zpool set autoexpand=on zroot root@zpool-test:~ # zpool online -e zroot gptid/352086bd-50b5-11e4-95b8-0050569b2a04 root@zpool-test:~ # zpool list NAMESIZE ALLOC FREECAP DEDUP HEALTH ALTROOT zroot 5.97G 876M 5.11G14% 1.00x ONLINE - The zpool appears to still only have 5.11G free. Lets reboot and try again ... Interesting. This used to work; actually either of those (autoexpand or online -e) should do the trick. root@zpool-test:~ # zpool set autoexpand=on zroot root@zpool-test:~ # zpool online -e zroot gptid/352086bd-50b5-11e4-95b8-0050569b2a04 root@zpool-test:~ # zpool list NAMESIZE ALLOC FREECAP DEDUP HEALTH ALTROOT zroot 14.0G 876M 13.1G 6% 1.00x ONLINE - Now I have 13.1G free. I can add this space to any of my zfs volumes and it picks the change up immediately. So the question remains, why do I need to reboot the OS twice to allocate new disk space to a volume? FreeBSD is first and foremost a server operating system. Servers are commonly deployed in data centers. Virtual environments are now commonplace in data centers, not the exception to the rule. VMware still has the vast majority of the private virutal environment market. I assume that most would expect things like this to work out of the box. Did I miss a required step or is this fixed in CURRENT? Looks like genuine bugs (or rather, one missing feature and one bug). Filling PRs for those might be a good idea. All, I know this is a very late follow up, but spent some more time looking at this today and found some additional information that I found quite interesting. I setup two VMs, one that acts as an iSCSI initiator ( CURRENT ) and another that acts as a target ( 10.2-RELEASE ). Both are running under ESXi v5.5. There are two block devices on the initiator, da1 and da2, that I used for resize testing ... [root@iscsi-i /home/mgrooms]# camcontrol devlist at scbus1 target 0 lun 0 (cd0,pass0) at scbus2 target 0 lun 0 (pass1,da0) at scbus2 target 1 lun 0 (pass2,da1) at scbus3 target 0 lun 0 (da2,pass3) The da1 device is a virtual disk hanging off of a VMware virtual SAS controller ... [root@iscsi-i /home/mgrooms]# pciconf ... mpt0@pci0:3:0:0:class=0x010700 card=0x197615ad chip=0x00541000 rev=0x01 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = 'SAS1068 PCI-X Fusion-MPT SAS' class = mass storage subclass = SAS [root@iscsi-i /home/mgrooms]# camcontrol readcap da1 -h Device Size: 10 G, Block Length: 512 bytes [root@iscsi-i /home/mgrooms]# gpart show da1 => 40 20971440 da1 GPT (10G) 40 209714401 freebsd-ufs (10G) The da2 device is an iSCSI LUN mounted from my FreeBSD 10.2 VM running ctld ... [root@iscsi-i /home/mgrooms]# iscsictl Target name Target portalState iqn.2015-01.lab.shrew:target0iscsi-t.shrew.lab Connected: da2 [root@iscsi-i /home/mgrooms]# camcontrol readcap da2 -h Device Size: 10 G, Block Length: 512 bytes [root@iscsi-i /home/mgrooms]# gpart show da2 =>
Build failure, undefined reference to __mq_oshandle
$ uname -a FreeBSD vega 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r277320: Mon Jan 19 09:02:50 EST 2015 deischen@vega:/usr/FreeBSD/svn/obj/usr/FreeBSD/svn/src/sys/vega amd64 Upgrading to today's current, 'rm -rf /usr/obj/*; make -j8 buildworld' fails here: ===> lib/libc/tests/gen/execve (buildconfig) --- all_subdir_tests --- --- all_subdir_mqueue --- mqtest3.o: In function `main': /usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x139): undefined reference to `__mq_oshandle' /usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x14c): undefined reference to `__mq_oshandle' /usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x16c): undefined reference to `__mq_oshandle' /usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x3e6): undefined reference to `__mq_oshandle' /usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x3f9): undefined reference to `__mq_oshandle' mqtest3.o:/usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x40f): more undefined references to `__mq_oshandle' follow cc: error: linker command failed with exit code 1 (use -v to see invocation) Going to try make [-j1], next, but anyone come across this? -- DE ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Build failure, undefined reference to __mq_oshandle
On Fri, 27 Nov 2015, Daniel Eischen wrote: $ uname -a FreeBSD vega 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r277320: Mon Jan 19 09:02:50 EST 2015 deischen@vega:/usr/FreeBSD/svn/obj/usr/FreeBSD/svn/src/sys/vega amd64 Upgrading to today's current, 'rm -rf /usr/obj/*; make -j8 buildworld' fails here: ===> lib/libc/tests/gen/execve (buildconfig) --- all_subdir_tests --- --- all_subdir_mqueue --- mqtest3.o: In function `main': /usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x139): undefined reference to `__mq_oshandle' /usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x14c): undefined reference to `__mq_oshandle' /usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x16c): undefined reference to `__mq_oshandle' /usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x3e6): undefined reference to `__mq_oshandle' /usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x3f9): undefined reference to `__mq_oshandle' mqtest3.o:/usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x40f): more undefined references to `__mq_oshandle' follow cc: error: linker command failed with exit code 1 (use -v to see invocation) Going to try make [-j1], next, but anyone come across this? Still fails. Why do the tests in tests/sys/mqueue/ try to use non-public APIs? -- DE ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD_HEAD_i386 - Build #1781 - Failure
FreeBSD_HEAD_i386 - Build #1781 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1781/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1781/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1781/console Change summaries: 291411 by adrian: [ath] conditionally print out the rate series information if ATH_DEBUG_XMIT is set. 291410 by tuexen: Take also the send queue and sent queue into account when triggering the sending of outgoing stream reset requests. MFC after: 3 days 291409 by emaste: kbdmap: include filename when reporting fopen() failure Previously only one of two cases reported the file name. Use the same error string in both cases. Sponsored by: The FreeBSD Foundation The end of the build log: [...truncated 173170 lines...] awk -f /usr/src/sys/conf/kmod_syms.awk coretemp.kld export_syms | xargs -J% objcopy % coretemp.kld --- coretemp.ko.full --- ld -Bshareable -d -warn-common -o coretemp.ko.full coretemp.kld --- coretemp.ko.debug --- objcopy --only-keep-debug coretemp.ko.full coretemp.ko.debug --- all_subdir_ath --- ctfconvert -L VERSION -g if_ath_alq.o --- all_subdir_coretemp --- --- coretemp.ko --- objcopy --strip-debug --add-gnu-debuglink=coretemp.ko.debug coretemp.ko.full coretemp.ko --- all_subdir_cp --- ===> cp (all) --- exdump.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/contrib/dev/acpica/components/executer/exdump.c --- modules-all --- --- cpddk.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/modules/cp/../../dev/cp/cpddk.c -o cpddk.o --- exdump.o --- ctfconvert -L VERSION -g exdump.o --- modules-all --- --- all_subdir_cpuctl --- ===> cpuctl (all) --- cpuctl.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/modules/cpuctl/../../dev/cpuctl/cpuctl.c -o cpuctl.o ctfconvert -L VERSION -g cpuctl.o --- cpuctl.kld --- ld -d -warn-common -r -d -o cpuctl.kld cpuctl.o ctfmerge -L VERSION -g -o cpuctl.kld cpuctl.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk cpuctl.kld export_syms | xargs -J% objcopy % cpuctl.kld --- cpuctl.ko.full --- ld -Bshareable -d -warn-common -o cpuctl.ko.full cpuctl.kld --- cpuctl.ko.debug --- objcopy --only-keep-debug cpuctl.ko.full cpuctl.ko.debug --- cpuctl.ko --- objcopy --strip-debug --add-gnu-debuglink=cpuctl.ko.debug cpuctl.ko.full cpuctl.ko --- all_subdir_cp --- --- if_cp.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef
FreeBSD_HEAD_amd64_gcc4.9 - Build #842 - Fixed
FreeBSD_HEAD_amd64_gcc4.9 - Build #842 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/842/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/842/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/842/console Change summaries: 291416 by adrian: Add AR9530 (honeybee) config option. 291415 by ume: Regen src.conf.5 for recent option changes. 291414 by ume: Fix breakage by recent collation change. LC_ALL has to be exported. 291413 by adrian: * Add device string for QCA955x (scorpion); * Add device ID and device string for QCA953x (honeybee). 291412 by adrian: wrap in ATH_DEBUG. Thanks sparc64 build! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Build failure, undefined reference to __mq_oshandle
Damn, please use deisc...@freebsd.org for replies. On Fri, 27 Nov 2015, Daniel Eischen wrote: On Fri, 27 Nov 2015, Daniel Eischen wrote: $ uname -a FreeBSD vega 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r277320: Mon Jan 19 09:02:50 EST 2015 deischen@vega:/usr/FreeBSD/svn/obj/usr/FreeBSD/svn/src/sys/vega amd64 Upgrading to today's current, 'rm -rf /usr/obj/*; make -j8 buildworld' fails here: ===> lib/libc/tests/gen/execve (buildconfig) --- all_subdir_tests --- --- all_subdir_mqueue --- mqtest3.o: In function `main': /usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x139): undefined reference to `__mq_oshandle' /usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x14c): undefined reference to `__mq_oshandle' /usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x16c): undefined reference to `__mq_oshandle' /usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x3e6): undefined reference to `__mq_oshandle' /usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x3f9): undefined reference to `__mq_oshandle' mqtest3.o:/usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x40f): more undefined references to `__mq_oshandle' follow cc: error: linker command failed with exit code 1 (use -v to see invocation) Going to try make [-j1], next, but anyone come across this? Still fails. Why do the tests in tests/sys/mqueue/ try to use non-public APIs? -- DE ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD_HEAD_amd64_gcc4.9 - Build #841 - Failure
FreeBSD_HEAD_amd64_gcc4.9 - Build #841 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/841/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/841/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/841/console Change summaries: 291411 by adrian: [ath] conditionally print out the rate series information if ATH_DEBUG_XMIT is set. 291410 by tuexen: Take also the send queue and sent queue into account when triggering the sending of outgoing stream reset requests. MFC after: 3 days 291409 by emaste: kbdmap: include filename when reporting fopen() failure Previously only one of two cases reported the file name. Use the same error string in both cases. Sponsored by: The FreeBSD Foundation The end of the build log: [...truncated 288432 lines...] ctfconvert -L VERSION -g ata-acerlabs.o --- ataacerlabs.ko.full --- /usr/local/x86_64-freebsd/bin/ld -d -warn-common -r -d -o ataacerlabs.ko.full ata-acerlabs.o ctfmerge -L VERSION -g -o ataacerlabs.ko.full ata-acerlabs.o :> export_syms awk -f /builds/FreeBSD_HEAD_amd64_gcc4.9/sys/conf/kmod_syms.awk ataacerlabs.ko.full export_syms | xargs -J% /usr/local/x86_64-freebsd/bin/objcopy % ataacerlabs.ko.full --- ataacerlabs.ko.debug --- /usr/local/x86_64-freebsd/bin/objcopy --only-keep-debug ataacerlabs.ko.full ataacerlabs.ko.debug --- ataacerlabs.ko --- /usr/local/x86_64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=ataacerlabs.ko.debug ataacerlabs.ko.full ataacerlabs.ko --- all_subdir_ataamd --- ===> ata/atapci/chipsets/ataamd (all) --- ata-amd.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include -L/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/lib --sysroot=/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/sys/GENERIC/opt_global.h -I. -I/builds/FreeBSD_HEAD_amd64_gcc4.9/sys -fno-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/sys/GENERIC -MD -MP -MF.depend.ata-amd.o -MTata-amd.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmis sing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error=inline -Wno-error=enum-compare -Wno-error=unused-but-set-variable -Wno-error=aggressive-loop-optimizations -Wno-error=maybe-uninitialized -Wno-error=array-bounds -Wno-error=address -Wno-error=cast-qual -Wno-error=sequence-point -Wno-error=attributes -Wno-error=strict-overflow -Wno-error=overflow -finline-limit=8000 -fms-extensions --param inline-unit-growth=100 --param large-function-growth=1000 -std=iso9899:1999 -c /builds/FreeBSD_HEAD_amd64_gcc4.9/sys/modules/ata/atapci/chipsets/ataamd/../../../../../dev/ata/chipsets/ata-amd.c -o ata-amd.o --- all_subdir_autofs --- ctfconvert -L VERSION -g autofs.o --- autofs_vnops.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include -L/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/lib --sysroot=/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/sys/GENERIC/opt_global.h -I. -I/builds/FreeBSD_HEAD_amd64_gcc4.9/sys -fno-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/sys/GENERIC -MD -MP -MF.depend.autofs_vnops.o -MTautofs_vnops.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error=inline -Wno-error=enum-compare -Wno-error=unused-but-set-variable -Wno-error=aggressive-loop-optimizations -Wno-error=maybe-uninitialized -Wno-error=array-bounds -Wno-error=address -Wno-error=cast-qual -Wno-error=sequence-point -Wno-error=attributes -Wno-error=strict-overflow
FreeBSD_HEAD_i386 - Build #1782 - Fixed
FreeBSD_HEAD_i386 - Build #1782 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1782/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1782/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1782/console Change summaries: 291416 by adrian: Add AR9530 (honeybee) config option. 291415 by ume: Regen src.conf.5 for recent option changes. 291414 by ume: Fix breakage by recent collation change. LC_ALL has to be exported. 291413 by adrian: * Add device string for QCA955x (scorpion); * Add device ID and device string for QCA953x (honeybee). 291412 by adrian: wrap in ATH_DEBUG. Thanks sparc64 build! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Resizing a zpool as a VMware ESXi guest ...
On 11/27/2015 12:56 PM, Matthew Grooms wrote: I thought it would be useful to get more output from the geom layer, similar to the camcontrol debug output ... [root@iscsi-i /home/mgrooms]# sysctl kern.geom.debugflags=0x81 When I resize the iSCSI LUN and run the 'camcontrol readcap da2 -h', I see this in the log output ... [root@iscsi-i /home/mgrooms]# tail -f /var/log/messages ... Nov 27 12:20:07 iscsi-i kernel: (pass3:iscsi1:0:0:0): Capacity data has changed Nov 27 12:20:07 iscsi-i kernel: g_post_event_x(0x80973850, 0xf80003f4e000, 1, 0) Nov 27 12:20:07 iscsi-i kernel: g_post_event_x(0x8097a6b0, 0xf80003f42b60, 2, 0) Nov 27 12:20:07 iscsi-i kernel: g_resize_provider_event(0xf800038c6700) Nov 27 12:20:07 iscsi-i kernel: g_part_resize(da2) Nov 27 12:20:07 iscsi-i kernel: GEOM_PART: da2 was automatically resized. Nov 27 12:20:07 iscsi-i kernel: Use `gpart commit da2` to save changes or `gpart undo da2` to revert them. Nov 27 12:20:07 iscsi-i kernel: g_raid_taste(RAID, da2) Nov 27 12:20:07 iscsi-i kernel: g_attach(0xf80003e64780, 0xf800038c6700) Nov 27 12:20:07 iscsi-i kernel: g_detach(0xf80003e64780) Nov 27 12:20:07 iscsi-i kernel: g_destroy_consumer(0xf80003e64780) Nov 27 12:20:07 iscsi-i kernel: g_destroy_geom(0xf800038c9c00(raid:taste)) Nov 27 12:20:07 iscsi-i kernel: g_label_taste(LABEL, da2) However, when I resize the VMDK disk and run the 'camcontrol readcap da1 -h' command, I see nothing in the log output. So it would appear that even though cam is reporting the new capacity in the command line output, the this info is not being forwarded to geom in this case. Maybe the VMware virtual SAS device ( mpt0 ) isn't reporting some special capability bit to cam which causes it to squelch the info? I'm not sure if this is useful but here is what the device info looks like at boot time ... mpt0: port 0x4000-0x40ff mem 0xfd4ec000-0xfd4e,0xfd4f-0xfd4f irq 18 at device 0.0 on pci3 mpt0: MPI Version=1.5.0.0 ... da0 at mpt0 bus 0 scbus2 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 20480MB (41943040 512 byte sectors) da0: quirks=0x40 da1 at mpt0 bus 0 scbus2 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 300.000MB/s transfers da1: Command Queueing enabled da1: 20480MB (41943040 512 byte sectors) da1: quirks=0x40 ... da2 at iscsi1 bus 0 scbus3 target 0 lun 0 da2: Fixed Direct Access SPC-4 SCSI device da2: Serial Number MYSERIAL 0 da2: 150.000MB/s transfers da2: Command Queueing enabled da2: 16384MB (33554432 512 byte sectors) I spent the day looking over the FreeBSD cam and scsi_da source code. After sprinkling a bunch of printf's around to see what code paths were being called, It's obvious that Edward was correct in assuming that ESXi doesn't return any 'Unit Attention' sense information in response to a 'Read Capacity' request. This kinda makes sense as ESXi emulates SCSI-2 disk devices and, as far as I can tell, the 0x2A/0x09 ASC/ASCQ sense code that denotes 'Capacity Data Has Changed' wasn't defined until the SCSCI-3 spec. It's frustrating that the only way to get the scsci_da code to call reprobe() is by receiving a command from the device. Would something like this work? ... 1) Register a callback using xpt_register_async( daasync, AC_REPROBE_DEVICE, path ) that calls reprobe() 2) Implement a new IOCTL in cam_xpt that camcontrol can call with the bus:target:lun as the argument 3) have cam_xpt capture the IOCTL request and call xpt_async( AC_REPROBE_DEVICE, path ) as a result This way users would have the option of manually asking cam to communicate the new size to geom. The only option now is one or more reboots to gain access to the increased disk capacity. If this sounds like a reasonable approach, I'll take a stab at implementing it. Thanks, -Matthew ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD_HEAD_amd64_gcc4.9 - Build #841 - Failure
SVN 291411 should have included the following to build correctly in the non-debug case: Index: sys/dev/ath/if_ath_tx_ht.c === --- sys/dev/ath/if_ath_tx_ht.c (revision 291411) +++ sys/dev/ath/if_ath_tx_ht.c (working copy) @@ -627,7 +627,7 @@ ath_rateseries_setup(sc, ni, bf, series); -#if 1 +#ifdef ATH_DEBUG if (sc->sc_debug & ATH_DEBUG_XMIT) ath_rateseries_print(sc, series); #endif On 11/27/15 18:45, jenkins-ad...@freebsd.org wrote: > FreeBSD_HEAD_amd64_gcc4.9 - Build #841 - Failure: > > Build information: > https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/841/ > Full change log: > https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/841/changes > Full build log: > https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/841/console > > Change summaries: > > 291411 by adrian: > [ath] conditionally print out the rate series information if ATH_DEBUG_XMIT > is set. > > 291410 by tuexen: > Take also the send queue and sent queue into account when triggering > the sending of outgoing stream reset requests. > > MFC after:3 days > > 291409 by emaste: > kbdmap: include filename when reporting fopen() failure > > Previously only one of two cases reported the file name. Use the same > error string in both cases. > > Sponsored by: The FreeBSD Foundation > > > > The end of the build log: > > [...truncated 288432 lines...] > ctfconvert -L VERSION -g ata-acerlabs.o > --- ataacerlabs.ko.full --- > /usr/local/x86_64-freebsd/bin/ld -d -warn-common -r -d -o ataacerlabs.ko.full > ata-acerlabs.o > ctfmerge -L VERSION -g -o ataacerlabs.ko.full ata-acerlabs.o > :> export_syms > awk -f /builds/FreeBSD_HEAD_amd64_gcc4.9/sys/conf/kmod_syms.awk > ataacerlabs.ko.full export_syms | xargs -J% > /usr/local/x86_64-freebsd/bin/objcopy % ataacerlabs.ko.full > --- ataacerlabs.ko.debug --- > /usr/local/x86_64-freebsd/bin/objcopy --only-keep-debug ataacerlabs.ko.full > ataacerlabs.ko.debug > --- ataacerlabs.ko --- > /usr/local/x86_64-freebsd/bin/objcopy --strip-debug > --add-gnu-debuglink=ataacerlabs.ko.debug ataacerlabs.ko.full ataacerlabs.ko > --- all_subdir_ataamd --- > ===> ata/atapci/chipsets/ataamd (all) > --- ata-amd.o --- > /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem > /builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include > > -L/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/lib > > --sysroot=/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp > -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -D_KERNEL > -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include > /builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/sys/GENERIC/opt_global.h > -I. -I/builds/FreeBSD_HEAD_amd64_gcc4.9/sys -fno-common -g > -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer > -I/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/sys/GENERIC > -MD -MP -MF.depend.ata-amd.o -MTata-amd.o -mcmodel=kernel -mno-red-zone > -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables > -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wm i s > sing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs > -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error=inline > -Wno-error=enum-compare -Wno-error=unused-but-set-variable > -Wno-error=aggressive-loop-optimizations -Wno-error=maybe-uninitialized > -Wno-error=array-bounds -Wno-error=address -Wno-error=cast-qual > -Wno-error=sequence-point -Wno-error=attributes -Wno-error=strict-overflow > -Wno-error=overflow -finline-limit=8000 -fms-extensions --param > inline-unit-growth=100 --param large-function-growth=1000 -std=iso9899:1999 > -c > /builds/FreeBSD_HEAD_amd64_gcc4.9/sys/modules/ata/atapci/chipsets/ataamd/../../../../../dev/ata/chipsets/ata-amd.c > -o ata-amd.o > --- all_subdir_autofs --- > ctfconvert -L VERSION -g autofs.o > --- autofs_vnops.o --- > /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem > /builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include > > -L/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/lib > > --sysroot=/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp > -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -D_KERNEL > -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include > /builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/sys/GENERIC/opt_global.h > -I. -I/builds/FreeBSD_HEAD_amd64_gcc4.9/sys -fno-common -g > -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer > -I/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/sys/GENERIC > -MD -MP
Re: Resizing a zpool as a VMware ESXi guest ...
On 27-11-2015 06:59, Matthew Grooms wrote: On 10/16/2014 3:10 AM, Edward Tomasz Napierała wrote: On 1010T1529, Matthew Grooms wrote: All, I am a long time user and advocate of FreeBSD and manage a several deployments of FreeBSD in a few data centers. Now that these environments are almost always virtual, it would make sense that FreeBSD support for basic features such as dynamic disk resizing. It looks like most of the parts are intended to work. Kudos to the FreeBSD foundation for seeing the need and sponsoring dynamic increase of online UFS filesystems via growfs. Unfortunately, it would appear that there are still problems in this area, such as ... a) cam/geom recognizing when a drive's size has increased b) zpool recognizing when a gpt partition size has increased For example, if I do an install of FreeBSD 10 on VMware using ZFS, I see the following ... root@zpool-test:~ # gpart show => 34 16777149 da0 GPT (8.0G) 34 10241 freebsd-boot (512K) 1058 41943042 freebsd-swap (2.0G) 4195362 125818213 freebsd-zfs (6.0G) If I increase the VM disk size using VMware to 16G and rescan using camcontrol, this is what I see ... "camcontrol rescan" does not force fetching the updated disk size. AFAIK there is no way to do that. However, this should happen automatically, if the "other side" properly sends proper Unit Attention after resizing. No idea why this doesn't happen with VMWare. Reboot obviously clears things up. [..] Now I want the claim the additional 14 gigs of space for my zpool ... root@zpool-test:~ # zpool status pool: zroot state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 gptid/352086bd-50b5-11e4-95b8-0050569b2a04 ONLINE 0 0 0 root@zpool-test:~ # zpool set autoexpand=on zroot root@zpool-test:~ # zpool online -e zroot gptid/352086bd-50b5-11e4-95b8-0050569b2a04 root@zpool-test:~ # zpool list NAMESIZE ALLOC FREECAP DEDUP HEALTH ALTROOT zroot 5.97G 876M 5.11G14% 1.00x ONLINE - The zpool appears to still only have 5.11G free. Lets reboot and try again ... Interesting. This used to work; actually either of those (autoexpand or online -e) should do the trick. root@zpool-test:~ # zpool set autoexpand=on zroot root@zpool-test:~ # zpool online -e zroot gptid/352086bd-50b5-11e4-95b8-0050569b2a04 root@zpool-test:~ # zpool list NAMESIZE ALLOC FREECAP DEDUP HEALTH ALTROOT zroot 14.0G 876M 13.1G 6% 1.00x ONLINE - Now I have 13.1G free. I can add this space to any of my zfs volumes and it picks the change up immediately. So the question remains, why do I need to reboot the OS twice to allocate new disk space to a volume? FreeBSD is first and foremost a server operating system. Servers are commonly deployed in data centers. Virtual environments are now commonplace in data centers, not the exception to the rule. VMware still has the vast majority of the private virutal environment market. I assume that most would expect things like this to work out of the box. Did I miss a required step or is this fixed in CURRENT? Looks like genuine bugs (or rather, one missing feature and one bug). Filling PRs for those might be a good idea. All, I know this is a very late follow up, but spent some more time looking at this today and found some additional information that I found quite interesting. I setup two VMs, one that acts as an iSCSI initiator ( CURRENT ) and another that acts as a target ( 10.2-RELEASE ). Both are running under ESXi v5.5. There are two block devices on the initiator, da1 and da2, that I used for resize testing ... [root@iscsi-i /home/mgrooms]# camcontrol devlist at scbus1 target 0 lun 0 (cd0,pass0) at scbus2 target 0 lun 0 (pass1,da0) at scbus2 target 1 lun 0 (pass2,da1) at scbus3 target 0 lun 0 (da2,pass3) The da1 device is a virtual disk hanging off of a VMware virtual SAS controller ... [root@iscsi-i /home/mgrooms]# pciconf ... mpt0@pci0:3:0:0:class=0x010700 card=0x197615ad chip=0x00541000 rev=0x01 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = 'SAS1068 PCI-X Fusion-MPT SAS' class = mass storage subclass = SAS [root@iscsi-i /home/mgrooms]# camcontrol readcap da1 -h Device Size: 10 G, Block Length: 512 bytes [root@iscsi-i /home/mgrooms]# gpart show da1 => 40 20971440 da1 GPT (10G) 40 209714401 freebsd-ufs (10G) The da2 device is an iSCSI LUN mounted from my FreeBSD 10.2 VM running ctld ... [root@iscsi-i /home/mgrooms]# iscsictl Target name Target portalState iqn.2015-01.lab.shrew:target0iscsi-t.shrew.lab Connected: da2 [root@iscsi-i /home/mgrooms]# camcontrol readcap da2 -h Device Size: 10 G, Block Length: 512 bytes [root@iscsi-i /home/mgrooms]#
