should TRIM be working on my ZFS L2ARC devices?
Hiya, Hopefully a simple question on TRIM + ZFS, I have a couple L2ARCs for a zpool on a test box, two different SSDs: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: OCZ-VERTEX4 1.5 ATA-9 SATA 3.x device ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 122104MB (250069680 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: INTEL SSDSC2CW120A3 400i ATA-9 SATA 3.x device ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad6 I'm just using a small piece of each one for the L2ARC per below: capacity operationsbandwidth pool alloc free read write read write --- - - - - - - tron 98.2G 3.53T 7 23 58.2K 970K mirror 49.1G 1.76T 3 11 29.2K 485K ada2 - - 1 5 15.4K 485K ada4 - - 1 5 14.7K 485K mirror 49.1G 1.76T 3 11 29.0K 485K ada3 - - 1 5 14.6K 485K ada5 - - 1 5 15.3K 485K cache- - - - - - gpt/larc0 2.89G 29.1G 0 5 9 201K gpt/larc1 2.12G 29.9G 0 1 9 148K --- - - - - - - I'm running 10.0-CURRENT #34 251520 and I never seen any successful trim events: kstat.zfs.misc.zio_trim.bytes: 0 kstat.zfs.misc.zio_trim.success: 0 kstat.zfs.misc.zio_trim.unsupported: 102 kstat.zfs.misc.zio_trim.failed: 0 kstat.zfs.misc.zio_trim.unsupported is always 0 and the other values stick at 0. Does the Vertex 4 and Intel 520 not work with TRIM on FreeBSD or is something else going on here? Like, will TRIM only kick in after each device gets full and pages start getting evicted ? Thanks! Dan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: should TRIM be working on my ZFS L2ARC devices?
- Original Message - From: Dan Mack m...@macktronics.com To: curr...@freebsd.org Sent: Saturday, June 08, 2013 4:56 PM Subject: should TRIM be working on my ZFS L2ARC devices? Hiya, Hopefully a simple question on TRIM + ZFS, I have a couple L2ARCs for a zpool on a test box, two different SSDs: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: OCZ-VERTEX4 1.5 ATA-9 SATA 3.x device ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 122104MB (250069680 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: INTEL SSDSC2CW120A3 400i ATA-9 SATA 3.x device ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad6 I'm just using a small piece of each one for the L2ARC per below: capacity operationsbandwidth pool alloc free read write read write --- - - - - - - tron 98.2G 3.53T 7 23 58.2K 970K mirror 49.1G 1.76T 3 11 29.2K 485K ada2 - - 1 5 15.4K 485K ada4 - - 1 5 14.7K 485K mirror 49.1G 1.76T 3 11 29.0K 485K ada3 - - 1 5 14.6K 485K ada5 - - 1 5 15.3K 485K cache- - - - - - gpt/larc0 2.89G 29.1G 0 5 9 201K gpt/larc1 2.12G 29.9G 0 1 9 148K --- - - - - - - I'm running 10.0-CURRENT #34 251520 and I never seen any successful trim events: kstat.zfs.misc.zio_trim.bytes: 0 kstat.zfs.misc.zio_trim.success: 0 kstat.zfs.misc.zio_trim.unsupported: 102 kstat.zfs.misc.zio_trim.failed: 0 kstat.zfs.misc.zio_trim.unsupported is always 0 and the other values stick at 0. Does the Vertex 4 and Intel 520 not work with TRIM on FreeBSD or is something else going on here? Connected to an controller which supports BIO_DELETE yes they should. Check with: camcontrol identify ada0 camcontrol identify ada1 Like, will TRIM only kick in after each device gets full and pages start getting evicted ? I would indeed expect ZFS to only evict data from the L2ARC when it becomes stale, assuming this is the case you may not see TRIM's as often as you might first expect. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 10-CURRENT i386 memstick snapshots broken?
On Fri, Jun 07, 2013 at 05:22:56PM -0400, Glen Barber wrote:
Has anyone else tried the i386 memstick and having the same problem?
Hmm. Thanks for the report. I'll take a look at the logs for i386, but
they are generated the same way as the amd64, so in theory should not
have any noticable difference.
Jimmy, thank you for reporting this. I'm honestly not quite sure how
this went unnoticed for so long.
So, basically here is what happens:
The scripts that run the weekly snapshot builds on FreeBSD.org check out
clean svn trees of head/ and stable/9 to use to seed chroot
environments, where the builds actually happen.
For amd64 and i386, native binaries are built, and installed into
scratch directories; for powerpc and powerpc64, I just use the amd64
binaries, because I cannot directly use the chroot binaries for
non-native architecture.
The scripts chroot into the scratch directories, and run the real
release builds. As Jimmy noted, the
src/release/${ARCH}/make-memstick.sh script is what generates the
memstick images. Part of that procedure is to create md(4) device, and
partition layout with gpart(8). This is where things blow up.
Because the userland is 32-bit and the kernel is 64-bit, something
goes wrong, but interestingly not wrong enough that the script fails
entirely. So, the paritions appear to be created, but in reality, they
are not.
So, for the snapshots case, the solution is to write the memstick image
from outside of the chroot environment, which is easy to do because
I already do this for creating the VM disk images (interestingly for the
same reason as the memstick creation failure).
Thanks to Jimmy for his patience in helping me make sure my solution
does in fact fix the problem, and the next set of 10.0-CURRENT and
9.1-STABLE i386 memsticks will not have this issue (builds are in-flight
now).
Glen
pgpueHbr_ho0d.pgp
Description: PGP signature
Re: should TRIM be working on my ZFS L2ARC devices?
On Sat, 8 Jun 2013, Steven Hartland wrote: snip Does the Vertex 4 and Intel 520 not work with TRIM on FreeBSD or is something else going on here? Connected to an controller which supports BIO_DELETE yes they should. Check with: camcontrol identify ada0 Feature Support Enabled Value Vendor read ahead no yes write cacheyes yes flush cacheyes yes overlapno Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no automatic acoustic management no no media status notification no no power-up in Standbyno no write-read-verify yes yes 0/0x0 unload no no free-fall no no Data Set Management (DSM/TRIM) yes DSM - max 512byte blocks yes 16 DSM - deterministic read no Host Protected Area (HPA) yes no 250069680/250069680 HPA - Security no camcontrol identify ada1 Feature Support Enabled Value Vendor read ahead yes yes write cacheyes yes flush cacheyes yes overlapno Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes yes 254/0xFE automatic acoustic management no no media status notification no no power-up in Standbyyes no write-read-verify no no unload yes yes free-fall no no Data Set Management (DSM/TRIM) yes DSM - max 512byte blocks yes 1 DSM - deterministic read yes any value Host Protected Area (HPA) yes no 234441648/234441648 HPA - Security no I don't see BIO_DELETE called out in the camcontrol output anywhere else but and the DSM/TRIM line is marked as supported with the enabled column ambiguous :-) Thanks for the help, Dan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: should TRIM be working on my ZFS L2ARC devices?
- Original Message - From: Dan Mack m...@macktronics.com To: Steven Hartland kill...@multiplay.co.uk Cc: curr...@freebsd.org Sent: Saturday, June 08, 2013 6:38 PM Subject: Re: should TRIM be working on my ZFS L2ARC devices? On Sat, 8 Jun 2013, Steven Hartland wrote: snip Does the Vertex 4 and Intel 520 not work with TRIM on FreeBSD or is something else going on here? Connected to an controller which supports BIO_DELETE yes they should. Check with: camcontrol identify ada0 Feature Support Enabled Value Vendor read ahead no yes write cacheyes yes flush cacheyes yes overlapno Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no automatic acoustic management no no media status notification no no power-up in Standbyno no write-read-verify yes yes 0/0x0 unload no no free-fall no no Data Set Management (DSM/TRIM) yes DSM - max 512byte blocks yes 16 DSM - deterministic read no Host Protected Area (HPA) yes no 250069680/250069680 HPA - Security no camcontrol identify ada1 Feature Support Enabled Value Vendor read ahead yes yes write cacheyes yes flush cacheyes yes overlapno Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes yes 254/0xFE automatic acoustic management no no media status notification no no power-up in Standbyyes no write-read-verify no no unload yes yes free-fall no no Data Set Management (DSM/TRIM) yes DSM - max 512byte blocks yes 1 DSM - deterministic read yes any value Host Protected Area (HPA) yes no 234441648/234441648 HPA - Security no I don't see BIO_DELETE called out in the camcontrol output anywhere else but and the DSM/TRIM line is marked as supported with the enabled column ambiguous :-) Yes thats what your looking for, attached to ataX this will be using ATA_TRIM requests to support BIO_DELETE. So the question is now have you simply not seen any data removed from your L2ARC vdev's or is there an issue with the L2ARC TRIM support. One way to try and force test this would be get your L2ARC full of data which you then remove from the pool as that should then be removed from L2ARC and hence TRIM'ed. zfs-stats -L or sysctl -a |grep -i l2 should be helpful on checking stats for this. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 10-CURRENT i386 memstick snapshots broken?
On Jun 8, 2013, at 10:34 AM, Glen Barber wrote: On Fri, Jun 07, 2013 at 05:22:56PM -0400, Glen Barber wrote: Has anyone else tried the i386 memstick and having the same problem? Hmm. Thanks for the report. I'll take a look at the logs for i386, but they are generated the same way as the amd64, so in theory should not have any noticable difference. For amd64 and i386, native binaries are built, and installed into scratch directories; for powerpc and powerpc64, I just use the amd64 binaries, because I cannot directly use the chroot binaries for non-native architecture. The scripts chroot into the scratch directories, and run the real release builds. Have you tried using Crochet for this sort of thing? Since it was designed from the ground up for cross-building bootable images, it should avoid these issues. The only fundamental limit right now is that Crochet uses the host system to build the UFS filesystems, so it can't build big-endian MIPS images on i386, for example. Tim signature.asc Description: Message signed with OpenPGP using GPGMail
Re: 10-CURRENT i386 memstick snapshots broken?
On Sat, Jun 08, 2013 at 12:10:16PM -0700, Tim Kientzle wrote: On Jun 8, 2013, at 10:34 AM, Glen Barber wrote: On Fri, Jun 07, 2013 at 05:22:56PM -0400, Glen Barber wrote: Has anyone else tried the i386 memstick and having the same problem? Hmm. Thanks for the report. I'll take a look at the logs for i386, but they are generated the same way as the amd64, so in theory should not have any noticable difference. For amd64 and i386, native binaries are built, and installed into scratch directories; for powerpc and powerpc64, I just use the amd64 binaries, because I cannot directly use the chroot binaries for non-native architecture. The scripts chroot into the scratch directories, and run the real release builds. Have you tried using Crochet for this sort of thing? Since it was designed from the ground up for cross-building bootable images, it should avoid these issues. I have not, primarily because I was not aware of crochet when I originally started this. Although, by using the release stuff from the base system, we do get a weekly run-test of the 'make release' bits in head/ and stable/9/, so in theory, there would be no surprises when it is -RELEASE time. The only fundamental limit right now is that Crochet uses the host system to build the UFS filesystems, so it can't build big-endian MIPS images on i386, for example. Yes, I have this same issue with sparc64. Glen pgpO68TBLrIbU.pgp Description: PGP signature
Re: 10-CURRENT i386 memstick snapshots broken?
Glen Barber g...@freebsd.org wrote in 20130608173411.gd13...@glenbarber.us: gj On Fri, Jun 07, 2013 at 05:22:56PM -0400, Glen Barber wrote: gj Because the userland is 32-bit and the kernel is 64-bit, something gj goes wrong, but interestingly not wrong enough that the script fails gj entirely. So, the paritions appear to be created, but in reality, they gj are not. gj gj So, for the snapshots case, the solution is to write the memstick image gj from outside of the chroot environment, which is easy to do because gj I already do this for creating the VM disk images (interestingly for the gj same reason as the memstick creation failure). I do not think there is a problem with cross building in chroot. allbsd.org is also generating i386 snapshots on an amd64 box in almost the same way as generate-release.sh, but the memstick images already generated were not broken as far as I can check. Although I do not use generate-release.sh on it because I added another build world stage in chroot before cross compiling, the difference is small. What was exactly gone wrong in 32-bit binary on 64-bit kernel? -- Hiroki pgpa7n05DnipG.pgp Description: PGP signature
Re: 10-CURRENT i386 memstick snapshots broken?
Tim Kientzle t...@kientzle.com wrote in 926ef579-8ac9-4a98-8a81-4e978a627...@kientzle.com: ti ti On Jun 8, 2013, at 10:34 AM, Glen Barber wrote: ti ti On Fri, Jun 07, 2013 at 05:22:56PM -0400, Glen Barber wrote: ti Has anyone else tried the i386 memstick and having the same problem? ti ti ti Hmm. Thanks for the report. I'll take a look at the logs for i386, but ti they are generated the same way as the amd64, so in theory should not ti have any noticable difference. ti ti ti For amd64 and i386, native binaries are built, and installed into ti scratch directories; for powerpc and powerpc64, I just use the amd64 ti binaries, because I cannot directly use the chroot binaries for ti non-native architecture. ti ti The scripts chroot into the scratch directories, and run the real ti release builds. ti ti Have you tried using Crochet for this sort of thing? ti ti Since it was designed from the ground up for cross-building ti bootable images, it should avoid these issues. ti ti The only fundamental limit right now is that Crochet uses ti the host system to build the UFS filesystems, so it can't ti build big-endian MIPS images on i386, for example. makefs does not work? It can build BE FFS images on LE platforms. -- Hiroki pgpSfiguwNi65.pgp Description: PGP signature
Re: 10-CURRENT i386 memstick snapshots broken?
On 06/08/13 14:17, Glen Barber wrote: On Sat, Jun 08, 2013 at 12:10:16PM -0700, Tim Kientzle wrote: On Jun 8, 2013, at 10:34 AM, Glen Barber wrote: On Fri, Jun 07, 2013 at 05:22:56PM -0400, Glen Barber wrote: Has anyone else tried the i386 memstick and having the same problem? Hmm. Thanks for the report. I'll take a look at the logs for i386, but they are generated the same way as the amd64, so in theory should not have any noticable difference. For amd64 and i386, native binaries are built, and installed into scratch directories; for powerpc and powerpc64, I just use the amd64 binaries, because I cannot directly use the chroot binaries for non-native architecture. The scripts chroot into the scratch directories, and run the real release builds. Have you tried using Crochet for this sort of thing? Since it was designed from the ground up for cross-building bootable images, it should avoid these issues. I have not, primarily because I was not aware of crochet when I originally started this. Although, by using the release stuff from the base system, we do get a weekly run-test of the 'make release' bits in head/ and stable/9/, so in theory, there would be no surprises when it is -RELEASE time. The only fundamental limit right now is that Crochet uses the host system to build the UFS filesystems, so it can't build big-endian MIPS images on i386, for example. Yes, I have this same issue with sparc64. Why not use makefs? It can build cross-endian UFS images. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 10-CURRENT i386 memstick snapshots broken?
On Sat, Jun 08, 2013 at 02:18:48PM -0500, Nathan Whitehorn wrote: On 06/08/13 14:17, Glen Barber wrote: On Sat, Jun 08, 2013 at 12:10:16PM -0700, Tim Kientzle wrote: On Jun 8, 2013, at 10:34 AM, Glen Barber wrote: On Fri, Jun 07, 2013 at 05:22:56PM -0400, Glen Barber wrote: Has anyone else tried the i386 memstick and having the same problem? Hmm. Thanks for the report. I'll take a look at the logs for i386, but they are generated the same way as the amd64, so in theory should not have any noticable difference. For amd64 and i386, native binaries are built, and installed into scratch directories; for powerpc and powerpc64, I just use the amd64 binaries, because I cannot directly use the chroot binaries for non-native architecture. The scripts chroot into the scratch directories, and run the real release builds. Have you tried using Crochet for this sort of thing? Since it was designed from the ground up for cross-building bootable images, it should avoid these issues. I have not, primarily because I was not aware of crochet when I originally started this. Although, by using the release stuff from the base system, we do get a weekly run-test of the 'make release' bits in head/ and stable/9/, so in theory, there would be no surprises when it is -RELEASE time. The only fundamental limit right now is that Crochet uses the host system to build the UFS filesystems, so it can't build big-endian MIPS images on i386, for example. Yes, I have this same issue with sparc64. Why not use makefs? It can build cross-endian UFS images. The scripts do (as far as I recall for sparc64) use makefs, but a port is needed to create the sparc-capable ISO image. Glen pgptKlnQa3HD9.pgp Description: PGP signature
Re: 10-CURRENT i386 memstick snapshots broken?
On Sun, Jun 09, 2013 at 05:01:00AM +0900, Hiroki Sato wrote: gj Because the userland is 32-bit and the kernel is 64-bit, something gj goes wrong, but interestingly not wrong enough that the script fails gj entirely. So, the paritions appear to be created, but in reality, they gj are not. gj gj So, for the snapshots case, the solution is to write the memstick image gj from outside of the chroot environment, which is easy to do because gj I already do this for creating the VM disk images (interestingly for the gj same reason as the memstick creation failure). I do not think there is a problem with cross building in chroot. cross-building, no, there is no problem. allbsd.org is also generating i386 snapshots on an amd64 box in almost the same way as generate-release.sh, but the memstick images already generated were not broken as far as I can check. Although I do not use generate-release.sh on it because I added another build world stage in chroot before cross compiling, the difference is small. What was exactly gone wrong in 32-bit binary on 64-bit kernel? The problem is creating the gpart(8) partition scheme on the md(4) device. Below follows script(1) output of what the make-memstick.sh script does: Script started on Sun Jun 9 00:41:08 2013 root@snap:/snap/releng # chroot /snap/releng/10-i386-snap root@snap:/ # cd /usr/obj/usr/src/release root@snap:/usr/obj/usr/src/release # echo \ '/dev/ufs/FreeBSD_Install / ufs ro,noatime 1 1' release/etc/fstab root@snap:/usr/obj/usr/src/release # makefs -B \ little -o label=FreeBSD_Install test.img release Calculated size of `test.img': 649420800 bytes, 12922 inodes Extent size set to 8192 test.img: 619.3MB (1268400 sectors) block size 8192, fragment size 1024 using 12 cylinder groups of 54.40MB, 6963 blks, 1152 inodes. super-block backups (for fsck -b #) at: 32, 111440, 222848, 334256, 445664, 557072, 668480, 779888, 891296, 1002704, 1114112, 1225520, Populating `test.img' Image `test.img' complete root@snap:/usr/obj/usr/src/release # mdconfig -a -t vnode -f test.img md0 All fine up until this point. Now the gpart(8) partition is created: root@snap:/usr/obj/usr/src/release # gpart create -s BSD /dev/md0 gpart: Inappropriate ioctl for device root@snap:/usr/obj/usr/src/release # gpart list md0 Segmentation fault (core dumped) I also ran into this when initially creating the 8.4-RELEASE memory stick images, which uses fdisk(8) instead of gpart(8). I basically attributed this to probably shouldn't be expected to work, such as doing netstat(1) on within 32-bit chroot/jail on a 64-bit kernel. root@snap:/usr/obj/usr/src/release # gdb -c ./gpart.core gpart GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd...(no debugging symbols found)... Core was generated by `gpart'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libgeom.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libgeom.so.5 Reading symbols from /lib/libsbuf.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libsbuf.so.6 Reading symbols from /lib/libbsdxml.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libbsdxml.so.4 Reading symbols from /lib/libutil.so.9...(no debugging symbols found)...done. Loaded symbols for /lib/libutil.so.9 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /lib/geom/geom_part.so...(no debugging symbols found)...done. Loaded symbols for /lib/geom/geom_part.so Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x28070205 in geom_deletetree () from /lib/libgeom.so.5 (gdb) bt #0 0x28070205 in geom_deletetree () from /lib/libgeom.so.5 #1 0x08049b43 in ?? () #2 0xcbf0 in ?? () #3 0x28813050 in ?? () #4 0x0804cb1a in ?? () #5 0x28813030 in ?? () #6 0x0804e63d in __stderrp () #7 0x in ?? () I can rebuild gpart(8) with debugging symbols enabled tomorrow. The machine is churning through builds at the moment. Glen pgpBED76ulpGg.pgp Description: PGP signature
Re: 10-CURRENT i386 memstick snapshots broken?
On Sat, 8 Jun 2013, Glen Barber wrote: The problem is creating the gpart(8) partition scheme on the md(4) device. Below follows script(1) output of what the make-memstick.sh script does: Script started on Sun Jun 9 00:41:08 2013 root@snap:/snap/releng # chroot /snap/releng/10-i386-snap root@snap:/ # cd /usr/obj/usr/src/release root@snap:/usr/obj/usr/src/release # echo \ '/dev/ufs/FreeBSD_Install / ufs ro,noatime 1 1' release/etc/fstab root@snap:/usr/obj/usr/src/release # makefs -B \ little -o label=FreeBSD_Install test.img release Calculated size of `test.img': 649420800 bytes, 12922 inodes Extent size set to 8192 test.img: 619.3MB (1268400 sectors) block size 8192, fragment size 1024 using 12 cylinder groups of 54.40MB, 6963 blks, 1152 inodes. super-block backups (for fsck -b #) at: 32, 111440, 222848, 334256, 445664, 557072, 668480, 779888, 891296, 1002704, 1114112, 1225520, Populating `test.img' Image `test.img' complete root@snap:/usr/obj/usr/src/release # mdconfig -a -t vnode -f test.img md0 All fine up until this point. Now the gpart(8) partition is created: root@snap:/usr/obj/usr/src/release # gpart create -s BSD /dev/md0 gpart: Inappropriate ioctl for device root@snap:/usr/obj/usr/src/release # gpart list md0 Segmentation fault (core dumped) This might be a good time to stop using a bare bsdlabel (aka dangerously dedicated). MBR plus bsdlabel is not great, but more widely understood, and other operating systems will at least recognize the MBR slice. I can help with this if needed. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
