From andrew at fubar.geek.nz Mon Jun 1 00:03:33 2009 From: andrew at fubar.geek.nz (Andrew Turner) Date: Mon Jun 1 00:03:40 2009 Subject: Sending BIO_GETATTR to disks Message-ID: <20090601114542.4cb80938@fubar.geek.nz> While working on a NAND flash driver I noticed a BIO_GETATTR request will not make it to the disk. It would be useful to support attributes in a NAND layer, eg. to get the size of the OOB region. I've attached a patch to pass the disk driver BIO_GETATTR when the new DISKFLAG_CANGETATTR is set. When DISKFLAG_CANGETATTR is unset it will act the same as currently and deliver ENOIOCTL. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: freebsd-geom_disk.diff Type: text/x-patch Size: 1328 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090601/7638f795/freebsd-geom_disk.bin From pjd at FreeBSD.org Mon Jun 1 08:38:53 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Mon Jun 1 08:39:00 2009 Subject: svn commit: r193112 - head/etc/rc.d In-Reply-To: References: <200905301938.n4UJcpbF017191@svn.freebsd.org> <4A22CFA1.3050408@FreeBSD.org> Message-ID: <20090601080646.GB1542@garage.freebsd.pl> On Sun, May 31, 2009 at 11:46:39PM +0400, Dmitry Morozovsky wrote: > On Sun, 31 May 2009, Doug Barton wrote: > > DB> Dmitry Morozovsky wrote: > DB> > Doug, > DB> > > DB> > On Sat, 30 May 2009, Doug Barton wrote: > DB> > > DB> > DB> Author: dougb > DB> > DB> Date: Sat May 30 19:38:51 2009 > DB> > DB> New Revision: 193112 > DB> > DB> URL: http://svn.freebsd.org/changeset/base/193112 > DB> > DB> > DB> > DB> Log: > DB> > DB> As previously advertised, remove this script prior to the 8.0 branch. > DB> > > DB> > Was there an agreement what should one do with dumping to gmirror (see > DB> > sbin/geom/class/mirror/gmirror.8) ? > DB> > DB> I'm not familiar with that issue, but it sounds like something that > DB> needs its own rc.d script. If someone who knows what is supposed to > DB> happen wants to write something up and send it to the freebsd-rc@ list > DB> I'll be glad to help review it. > > Something like (checks should be added, yeah) > > #!/bin/sh > # > # $FreeBSD$ > # > > # BEFORE: savecore > # PROVIDE: gmirror-savecore > # KEYWORD: nojail > > . /etc/rc.subr > > name="gmirror_savecore" > start_cmd="gmsavecore_start" > stop_cmd=":" > > gmsavecore_start() > { > gmirror configure -b prefer /dev/dumpdev > } > > load_rc_config $name > run_rc_command "$1" > > possibly? It's not that simple... First you have to remember previous balance algorithm and recover it once dumping crash dump is done. You also have to check if dumpdev is placed somewhere on a gmirror provider, which is not that simple, unfortunately. Imagine your dump partition is called /dev/label/dump and there is a long way to gmirror provider: label/dump -> mirror/root0s1b -> mirror/root0s1 -> mirror/root0 You can't just call 'gmirror configure -b prefer /dev/label/dump'. I'm happy to review another patch, but I don't really have any bright idea of how this should be implemented:) -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090601/053d74a3/attachment.pgp From bugmaster at FreeBSD.org Mon Jun 1 11:06:57 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 1 11:08:10 2009 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200906011106.n51B6pxt021071@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/134922 geom kernel panic when use fdisk on disk who been removed f o kern/134113 geom [geli] Problem setting secondary GELI key o kern/134044 geom [geom] gmirror(8) overwrites fs with stale data from r o kern/133931 geom [geli] [request] intentionally wrong password to destr o bin/132845 geom [geom] [patch] ggated(8) does not close files opened a o kern/132273 geom glabel(8): [patch] failing on journaled partition o kern/132242 geom [gmirror] gmirror.ko fails to fully initialize o kern/131353 geom [geom] gjournal(8) kernel lock o kern/131037 geom [geli] Unable to create disklabel on .eli-Device p docs/130548 geom [patch] gjournal(8) man page is missing sysctls o kern/130528 geom gjournal fsck during boot o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid o bin/128398 geom [patch] glabel(8): teach geom_label to recognise gpt l f kern/128276 geom [gmirror] machine lock up when gmirror module is used o kern/126902 geom [geom] geom_label: kernel panic during install boot o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s o kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin o kern/124130 geom [gmirror] [usb] gmirror fails to start usb devices tha o kern/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123630 geom [patch] [gmirror] gmirror doesnt allow the original dr o kern/123122 geom [geom] GEOM / gjournal kernel lock o kern/122738 geom [geom] gmirror list "losts consumers" after gmirror de f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/121481 geom [gmirror] data rot on disk with gmirror o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120231 geom [geom] GEOM_CONCAT error adding second drive o kern/120091 geom [geom] [geli] [gjournal] geli does not prompt for pass o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis o kern/120021 geom [geom] [panic] net-p2p/qbittorrent crashes system when o kern/119743 geom [geom] geom label for cds is keeped after dismount and p kern/116896 geom [geom] [patch] Typo in a kassert in GEOM o kern/115856 geom [geli] ZFS thought it was degraded when it should have o kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113885 geom [gmirror] [patch] improved gmirror balance algorithm o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back p bin/110705 geom gmirror(8) control utility does not exit with correct o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o bin/90093 geom fdisk(8) incapable of altering in-core geometry a kern/89660 geom [vinum] [patch] [panic] due to g_malloc returning null o kern/89546 geom [geom] GEOM error s kern/89102 geom [geom] [panic] panic when forced unmount FS from unplu o kern/88601 geom [geli] geli cause kernel panic under heavy disk usage o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu o bin/81779 geom misleading error messages in geom(8) utilities. o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o bin/78131 geom gbde(8) "destroy" not working. s kern/73177 geom kldload geom_* causes panic due to memory exhaustion 61 problems total. From don_read at att.net Mon Jun 1 19:23:34 2009 From: don_read at att.net (Don Read) Date: Mon Jun 1 19:23:40 2009 Subject: FreeBSD on USB drive for a MacBook Pro In-Reply-To: <200905302136.49369.lists@jnielsen.net> References: <200905302136.49369.lists@jnielsen.net> Message-ID: <20090601145650.5cef1601@att.net> On Sat, 30 May 2009 21:36:49 -0400 John Nielsen said: > I'm looking for advice and/or pointers. I have an Intel-based MacBook Pro > and I would like to use a USB thumb drive to be able to boot FreeBSD on > it. This should get you started: http://groups.google.com/group/lucky.freebsd.questions/msg/5c759b1c87376b22?pli=1 Regards, -- Don Read don_read@att.net It's always darkest before the dawn. So if you are going to steal the neighbor's newspaper, that's the time to do it. From stadtkind2 at gmx.de Tue Jun 2 11:27:53 2009 From: stadtkind2 at gmx.de (=?ISO-8859-1?Q?Stefan_Kr=FCger?=) Date: Tue Jun 2 11:28:25 2009 Subject: problems using geli on top of gmirror Message-ID: <4A250674.7080706@gmx.de> hello list, I have some problems using geli and gmirror (gm0 consists of ad0 and ad2) together, here's my test-setup: $ uname -sr FreeBSD 7.2-RELEASE $ ls -hl /dev/mirror/gm0s1* crw-r----- 1 root operator 0, 76 Jun 2 12:17 /dev/mirror/gm0s1 crw-r----- 1 root operator 0, 77 Jun 2 12:17 /dev/mirror/gm0s1a crw-r----- 1 root operator 0, 78 Jun 2 12:17 /dev/mirror/gm0s1b crw-r----- 1 root operator 0, 91 Jun 2 12:17 /dev/mirror/gm0s1b.eli crw-r----- 1 root operator 0, 79 Jun 2 12:17 /dev/mirror/gm0s1c crw-r----- 1 root operator 0, 80 Jun 2 12:21 /dev/mirror/gm0s1d # bsdlabel /dev/mirror/gm0s1 # /dev/mirror/gm0s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 8388608 0 4.2BSD 2048 16384 28552 b: 2097152 8388608 swap c: 12583809 0 unused 0 0 # "raw" part, don't edit d: 2098049 10485760 4.2BSD 2048 16384 28552 As you can see, encrypting the swap partition with # geli onetime -s 4096 -d /dev/mirror/gm0s1b already worked fine, but trying to do # geli init -s 4096 -K /boot/keys/gm0s1d.key /dev/mirror/gm0s1d returns geli: Cannot store metadata on /dev/mirror/gm0s1d: No such file or directory so my question is, is that even possible? and if yes, what wrong with my setup? From dan.naumov at gmail.com Wed Jun 3 22:11:53 2009 From: dan.naumov at gmail.com (Dan Naumov) Date: Wed Jun 3 22:11:59 2009 Subject: GELI and dynamically sized file providers? Message-ID: Hello list. As far as I know, this feature hasn't been implemented (if it is, by all means please educate me on this) and I think it would make a really good addition to the current options of using GELI encryption on FreeBSD. What I want is to have data encrypted with GELI and kept inside an encrypted file that is held on a regular ZFS or UFS2 partition. Now I know it is possible to just dd an arbitrarily sized block of data as a file onto the partition and use it as a provider for GELI, but this has a very serious limitation: you cannot resize this file without essentially have to move all your data out, delete the provider, create a new smaller/bigger file, use it as a new provider for GELI and then move the data back inside it. This is really really cumbersome. What would be really nice is to have this block of data used as a provider to dynamically grow or shrink as more or less is needed to store the encrypted files. This would open up a lot of options for the user: 1) You would be able to start small and then grow your amount of encrypted data for as long as you have free space on the ZFS / UFS2 partition holding the dynamic file provider. 2) If you end up overestimating your need for the amount of data you want to be encrypted, the provider shrinks accordingly, leaving more space free on the ZFS / UFS2 partition for use for unencrypted data without any speed penalties that come with using encryption. 3) This makes combining data redundancy and encryption a LOT easier: for example you can have a 4 disk ZFS raidz of 2tb disks (resulting in 6tb of space usable) and a dynamic file provider kept on this raidz than grows or shrinks according to space requirements of the encrypted files AND your data integrity and redundancy is on the shoulders of ZFS instead of having the user ponder the most non-insane way of doing things and avoiding things like having to keep separate partitions used as providers for 4 different GELI devices that each have to be "opened" with a passkey before the ZFS pool can be brought online or having to keep one ENORMOUS file container inside the ZFS pool taking up a lot of space without you ever knowing if you are going to ever use it all. - Dan Naumov From bo.coopci at i-waihui.com Thu Jun 4 09:00:30 2009 From: bo.coopci at i-waihui.com (cooper) Date: Thu Jun 4 09:00:36 2009 Subject: Questions about g_mbr and g_bsd Message-ID: <4A27866D.6010103@gmail.com> g_mbr_start and g_bsd_start care only if (bp->bio_cmd == BIO_GETATTR). Does anyone know why they neither do somthing similar to g_disk_start nor invoke the underlying g_disk? Thanks From phk at phk.freebsd.dk Thu Jun 4 09:26:23 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu Jun 4 09:26:30 2009 Subject: Questions about g_mbr and g_bsd In-Reply-To: Your message of "Thu, 04 Jun 2009 16:31:41 +0800." <4A27866D.6010103@gmail.com> Message-ID: <10765.1244106633@critter.freebsd.dk> In message <4A27866D.6010103@gmail.com>, cooper writes: >g_mbr_start and g_bsd_start care only if (bp->bio_cmd == BIO_GETATTR). >Does anyone know why they neither do somthing similar to g_disk_start >nor invoke the underlying g_disk? No they dont, all other request types are handled by the "slicer" code which they control with data structures describing the layout. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From juli at clockworksquid.com Thu Jun 4 23:49:06 2009 From: juli at clockworksquid.com (Juli Mallett) Date: Thu Jun 4 23:49:12 2009 Subject: Is anything being done to un-break partition names? Message-ID: Hey folks, If I install 7.2 (or old 8-CURRENT) and partition a drive "dangerously dedicated" and answer No when asked if I want to create a true partition entry, and then install as normal, my system is set up with partitions named like da0s1a. Newer 8-CURRENT instead names the devices da0a, which means root mount fails, etc., until one updates /etc/fstab. This also seems to confuse sysinstall, which appears to expect labeling da0s1 to work even if you're in dangerously-dedicated mode ? though I might be misunderstanding the interactions there; randi@ suggests it's just a problem with sanitizing disk names in libdisk, although when I built sysinstall with a patched libdisk and tried to use it when booting from an 8-CURRENT (snapshot as of a few weeks back) livefs disk, it seemed to have other problems with the device names. This seems like a huge POLA violation and has eaten several hours of my life in terms of fixing servers that were tracking 8-CURRENT and failed to boot up because of the need to change /etc/fstab that wasn't documented in UPDATING. Is anything being done to add compatibility slice names, or to teach mergemaster about the change? I don't know enough about what all is going on on disk to know whether this is something that just affects dangerously-dedicated disks, but it seems to be consistently biting me, and I can only imagine how much trouble it's going to cause others. Was this change even intentional? Juli. From pjd at FreeBSD.org Fri Jun 5 05:12:09 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Fri Jun 5 05:12:16 2009 Subject: Is anything being done to un-break partition names? In-Reply-To: References: Message-ID: <20090605051203.GD1705@garage.freebsd.pl> On Thu, Jun 04, 2009 at 04:18:09PM -0700, Juli Mallett wrote: > Hey folks, > > If I install 7.2 (or old 8-CURRENT) and partition a drive "dangerously > dedicated" and answer No when asked if I want to create a true > partition entry, and then install as normal, my system is set up with > partitions named like da0s1a. Newer 8-CURRENT instead names the > devices da0a, which means root mount fails, etc., until one updates > /etc/fstab. This also seems to confuse sysinstall, which appears to > expect labeling da0s1 to work even if you're in dangerously-dedicated > mode ? though I might be misunderstanding the interactions there; > randi@ suggests it's just a problem with sanitizing disk names in > libdisk, although when I built sysinstall with a patched libdisk and > tried to use it when booting from an 8-CURRENT (snapshot as of a few > weeks back) livefs disk, it seemed to have other problems with the > device names. > > This seems like a huge POLA violation and has eaten several hours of > my life in terms of fixing servers that were tracking 8-CURRENT and > failed to boot up because of the need to change /etc/fstab that wasn't > documented in UPDATING. I was bitten by the exactly the same thing. Unfortunately in my case I was upgrading from 7.0 or something and kernel.old didn't work for me with new userland. So I had to compile GEOM_PART_MBR out and compiled GEOM_MBR in, everything on another machine and then transfer new kernel using nc(1) and tar(1), because sshd(8) didn't work properly. And I was in a hury. All in all, a huge disappointment. BTW. I wasn't able to boot my system using ufs:/dev/ad0a on mountroot prompt. > Is anything being done to add compatibility slice names, or to teach > mergemaster about the change? I don't know enough about what all is > going on on disk to know whether this is something that just affects > dangerously-dedicated disks, but it seems to be consistently biting > me, and I can only imagine how much trouble it's going to cause > others. Was this change even intentional? I don't think it was. For me it's a bug in GEOM_PART_MBR, which has problems detecting MBRs properly. Shame on you, Marcel!:) -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090605/d5ccdbc8/attachment.pgp From pjd at FreeBSD.org Fri Jun 5 20:05:19 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Fri Jun 5 20:05:25 2009 Subject: Is anything being done to un-break partition names? In-Reply-To: <46FB00ED-62DC-4924-A84A-8C34B26DA22E@mac.com> References: <20090605051203.GD1705@garage.freebsd.pl> <46FB00ED-62DC-4924-A84A-8C34B26DA22E@mac.com> Message-ID: <20090605200512.GA2313@garage.freebsd.pl> On Fri, Jun 05, 2009 at 12:26:04PM -0700, Marcel Moolenaar wrote: > > On Jun 4, 2009, at 10:12 PM, Pawel Jakub Dawidek wrote: > > >On Thu, Jun 04, 2009 at 04:18:09PM -0700, Juli Mallett wrote: > >>Hey folks, > >> > >>If I install 7.2 (or old 8-CURRENT) and partition a drive > >>"dangerously > >>dedicated" and answer No when asked if I want to create a true > >>partition entry, and then install as normal, my system is set up with > >>partitions named like da0s1a. > > That's your problem. In a DD setup, you don't have slices. > > >> Newer 8-CURRENT instead names the > >>devices da0a, > > This is correct. > > > > >I don't think it was. For me it's a bug in GEOM_PART_MBR, which has > >problems detecting MBRs properly. > > > >Shame on you, Marcel!:) > > The bug is on your disk and as such in sysinstall. GEOM_PART_MBR > detects the MBR just fine. If you don't have GEOM_PART_BSD in > your kernel your will in fact get the MBR slices. The problem > for you is in the fact that you have a BSD disklabel in sector > 2, which takes precedence. A disk partitioned as a BSD disklabel > nested in an MBR slice can *NEVER* have a BSD disklabel in the > 2nd sector on the disk. The fact that there is a BSD disklabel > in sector 2 means that the disk is DD and that is what you get > for gpart. This is interesting: bridge:root:~# bsdlabel /dev/ad0 # /dev/ad0: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 10497792 16 unused 0 0 b: 2097152 10497808 swap c: 12594960 0 unused 0 0 # "raw" part, don't edit bridge:root:~# bsdlabel /dev/ad0s1 # /dev/ad0s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 12070609 524288 4.2BSD 2048 16384 28552 b: 524288 0 swap c: 12594897 0 unused 0 0 # "raw" part, don't edit Anyway, why BSD disklabel takes precedence over MBR for gpart? Are you happy with users upgrading their system and finding it no longer boots? I think that even a note in UPDATING is not enough, we should really make it to just work after the upgrade. Why not to change priorities and accept MBR first? -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090605/d71f26bb/attachment.pgp From jmallet at freebsd.org Fri Jun 5 20:14:55 2009 From: jmallet at freebsd.org (Juli Mallett) Date: Fri Jun 5 20:15:07 2009 Subject: Is anything being done to un-break partition names? In-Reply-To: <46FB00ED-62DC-4924-A84A-8C34B26DA22E@mac.com> References: <20090605051203.GD1705@garage.freebsd.pl> <46FB00ED-62DC-4924-A84A-8C34B26DA22E@mac.com> Message-ID: On Fri, Jun 5, 2009 at 12:26 PM, Marcel Moolenaar wrote: > On Jun 4, 2009, at 10:12 PM, Pawel Jakub Dawidek wrote: >> On Thu, Jun 04, 2009 at 04:18:09PM -0700, Juli Mallett wrote: >>> >>> Hey folks, >>> >>> If I install 7.2 (or old 8-CURRENT) and partition a drive "dangerously >>> dedicated" and answer No when asked if I want to create a true >>> partition entry, and then install as normal, my system is set up with >>> partitions named like da0s1a. > > That's your problem. In a DD setup, you don't have slices. I'm not arguing about whether the names are technically correct ? I'm concerned about POLA violations and the undocumented breakage of legitimately-installed systems. Could you please at least document this in UPDATING? It's a pretty major change and I wouldn't be so cavalier as to dismiss it as the problem of the users in question. DD configurations have worked historically and have been upgradable. I presume that the owner of libdisk/sysinstall will fix sysinstall's expectations of DD disks or remove support for them (and remove support for upgrading them or installing to disks which have already been partitioned and labeled which are DD.) Juli. From phk at phk.freebsd.dk Fri Jun 5 20:26:05 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri Jun 5 20:26:12 2009 Subject: Is anything being done to un-break partition names? In-Reply-To: Your message of "Fri, 05 Jun 2009 13:14:33 MST." Message-ID: <7193.1244233575@critter.freebsd.dk> In message , Juli Mallett writes: >> That's your problem. In a DD setup, you don't have slices. > >I'm not arguing about whether the names are technically correct =97 I'm >concerned about POLA violations and the undocumented breakage of >legitimately-installed systems. DD has not been "legitimate" since 4.x releases. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From xcllnt at mac.com Fri Jun 5 20:26:15 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Fri Jun 5 20:26:21 2009 Subject: Is anything being done to un-break partition names? In-Reply-To: <20090605051203.GD1705@garage.freebsd.pl> References: <20090605051203.GD1705@garage.freebsd.pl> Message-ID: <46FB00ED-62DC-4924-A84A-8C34B26DA22E@mac.com> On Jun 4, 2009, at 10:12 PM, Pawel Jakub Dawidek wrote: > On Thu, Jun 04, 2009 at 04:18:09PM -0700, Juli Mallett wrote: >> Hey folks, >> >> If I install 7.2 (or old 8-CURRENT) and partition a drive >> "dangerously >> dedicated" and answer No when asked if I want to create a true >> partition entry, and then install as normal, my system is set up with >> partitions named like da0s1a. That's your problem. In a DD setup, you don't have slices. >> Newer 8-CURRENT instead names the >> devices da0a, This is correct. > > I don't think it was. For me it's a bug in GEOM_PART_MBR, which has > problems detecting MBRs properly. > > Shame on you, Marcel!:) The bug is on your disk and as such in sysinstall. GEOM_PART_MBR detects the MBR just fine. If you don't have GEOM_PART_BSD in your kernel your will in fact get the MBR slices. The problem for you is in the fact that you have a BSD disklabel in sector 2, which takes precedence. A disk partitioned as a BSD disklabel nested in an MBR slice can *NEVER* have a BSD disklabel in the 2nd sector on the disk. The fact that there is a BSD disklabel in sector 2 means that the disk is DD and that is what you get for gpart. FYI, -- Marcel Moolenaar xcllnt@mac.com From xcllnt at mac.com Fri Jun 5 20:38:35 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Fri Jun 5 20:38:41 2009 Subject: Is anything being done to un-break partition names? In-Reply-To: <20090605200512.GA2313@garage.freebsd.pl> References: <20090605051203.GD1705@garage.freebsd.pl> <46FB00ED-62DC-4924-A84A-8C34B26DA22E@mac.com> <20090605200512.GA2313@garage.freebsd.pl> Message-ID: <5BE6CEC9-8F49-473B-A3E4-2702680A8836@mac.com> On Jun 5, 2009, at 1:05 PM, Pawel Jakub Dawidek wrote: > On Fri, Jun 05, 2009 at 12:26:04PM -0700, Marcel Moolenaar wrote: >> >> On Jun 4, 2009, at 10:12 PM, Pawel Jakub Dawidek wrote: >> >>> On Thu, Jun 04, 2009 at 04:18:09PM -0700, Juli Mallett wrote: >>>> Hey folks, >>>> >>>> If I install 7.2 (or old 8-CURRENT) and partition a drive >>>> "dangerously >>>> dedicated" and answer No when asked if I want to create a true >>>> partition entry, and then install as normal, my system is set up >>>> with >>>> partitions named like da0s1a. >> >> That's your problem. In a DD setup, you don't have slices. >> >>>> Newer 8-CURRENT instead names the >>>> devices da0a, >> >> This is correct. >> >>> >>> I don't think it was. For me it's a bug in GEOM_PART_MBR, which has >>> problems detecting MBRs properly. >>> >>> Shame on you, Marcel!:) >> >> The bug is on your disk and as such in sysinstall. GEOM_PART_MBR >> detects the MBR just fine. If you don't have GEOM_PART_BSD in >> your kernel your will in fact get the MBR slices. The problem >> for you is in the fact that you have a BSD disklabel in sector >> 2, which takes precedence. A disk partitioned as a BSD disklabel >> nested in an MBR slice can *NEVER* have a BSD disklabel in the >> 2nd sector on the disk. The fact that there is a BSD disklabel >> in sector 2 means that the disk is DD and that is what you get >> for gpart. > > This is interesting: > > bridge:root:~# bsdlabel /dev/ad0 > # /dev/ad0: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > a: 10497792 16 unused 0 0 > b: 2097152 10497808 swap > c: 12594960 0 unused 0 0 # "raw" part, > don't edit > bridge:root:~# bsdlabel /dev/ad0s1 > # /dev/ad0s1: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > a: 12070609 524288 4.2BSD 2048 16384 28552 > b: 524288 0 swap > c: 12594897 0 unused 0 0 # "raw" part, > don't edit > > Anyway, why BSD disklabel takes precedence over MBR for gpart? The BSD disklabel has an MBR immediately preceding it. While the MBR by definition has no valid partition information, there are 2 reasons not to take this too seriously during the taste: 1. By design GPT can only have a PMBR, but this has not been enforced in practice. As such, the existence of valid MBR slices is not a reason to ignore the GPT. The BSD disklabel follows this principle by virtue of having a MBR compliant boot record immediately ahead of it, like GPT. 2. False negatives cannot not be eliminated when ignoring the BSD disklabel when the MBR has slices. It's better to bank on the fact that there cannot be a BSD disklabel immediately following the MBR when that disklabel is actually nested and inside a MBR slice. Thus the existence of the BSD disklabel in sector 2 is enough proof that the MBR is part of the BSD disklabel and not on its own. Just like with GPT. > Are you happy with users upgrading their system and finding it no > longer > boots? I'm not happy about it, but I haven't found an acceptable solution until this discussion (but see below). > I think that even a note in UPDATING is not enough, we should really > make it to just work after the upgrade. Why not to change priorities > and > accept MBR first? That introduces significant breakages in normal setups. The priority should not be changed. It's resulting in the right behaviour and any exceptions to that (i.e. we need the wrong behaviour) should be coded explicitly. The closest we can get is by having the BSD disklabel code check if there are valid MBR partitions defined and if yes, back-off. This covers exactly the problem case and doesn't introduce false negatives in other scenarios. But: we should fix sysinstall as well. Either we should finally rip out DD or we should have it create proper DD images... -- Marcel Moolenaar xcllnt@mac.com From bugmaster at FreeBSD.org Mon Jun 8 11:06:53 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 8 11:08:17 2009 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200906081106.n58B6q6E020638@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/134922 geom [gmirror] [panic] kernel panic when use fdisk on disk o kern/134113 geom [geli] Problem setting secondary GELI key o kern/134044 geom [geom] gmirror(8) overwrites fs with stale data from r o kern/133931 geom [geli] [request] intentionally wrong password to destr o bin/132845 geom [geom] [patch] ggated(8) does not close files opened a o kern/132273 geom glabel(8): [patch] failing on journaled partition o kern/132242 geom [gmirror] gmirror.ko fails to fully initialize o kern/131353 geom [geom] gjournal(8) kernel lock o kern/131037 geom [geli] Unable to create disklabel on .eli-Device p docs/130548 geom [patch] gjournal(8) man page is missing sysctls o kern/130528 geom gjournal fsck during boot o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid o bin/128398 geom [patch] glabel(8): teach geom_label to recognise gpt l f kern/128276 geom [gmirror] machine lock up when gmirror module is used o kern/126902 geom [geom] geom_label: kernel panic during install boot o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s o kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin o kern/124130 geom [gmirror] [usb] gmirror fails to start usb devices tha o kern/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123630 geom [patch] [gmirror] gmirror doesnt allow the original dr o kern/123122 geom [geom] GEOM / gjournal kernel lock o kern/122738 geom [geom] gmirror list "losts consumers" after gmirror de f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/121481 geom [gmirror] data rot on disk with gmirror o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120231 geom [geom] GEOM_CONCAT error adding second drive o kern/120091 geom [geom] [geli] [gjournal] geli does not prompt for pass o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis o kern/120021 geom [geom] [panic] net-p2p/qbittorrent crashes system when o kern/119743 geom [geom] geom label for cds is keeped after dismount and p kern/116896 geom [geom] [patch] Typo in a kassert in GEOM o kern/115856 geom [geli] ZFS thought it was degraded when it should have o kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113885 geom [gmirror] [patch] improved gmirror balance algorithm o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back p bin/110705 geom gmirror(8) control utility does not exit with correct o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o bin/90093 geom fdisk(8) incapable of altering in-core geometry a kern/89660 geom [vinum] [patch] [panic] due to g_malloc returning null o kern/89546 geom [geom] GEOM error s kern/89102 geom [geom] [panic] panic when forced unmount FS from unplu o kern/88601 geom [geli] geli cause kernel panic under heavy disk usage o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu o bin/81779 geom misleading error messages in geom(8) utilities. o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o bin/78131 geom gbde(8) "destroy" not working. s kern/73177 geom kldload geom_* causes panic due to memory exhaustion 61 problems total. From jeff+freebsd at wagsky.com Mon Jun 8 19:47:08 2009 From: jeff+freebsd at wagsky.com (Jeff Kletsky) Date: Mon Jun 8 19:48:11 2009 Subject: GPT fails to be recognized by BIOS boot, Intel Atom 330 D945GCLF2, 7.2-RELEASE Message-ID: <4A2D6652.4050008@wagsky.com> I'm puzzled -- the eventual goal was to get GPT/gmirror/gjournal up and running on four boxes here, at least until ZFS boot was a little more mainstream. After getting what I thought to be a good configuration built up and installed on, it failed to boot. I confirmed that I could build a MBR-based system on the same drive on the same platform (Intel Atom 330 on Intel D945GCLF2 motherboard, 2 GB RAM, BIOS LF94510J.86A.0140.2008.1231.0012, later updated to BIOS LF94510J.86A.0182.2008.1231.0012) BIOS later than the troublesome one indicated in http://www.freebsd.org/cgi/getmsg.cgi?fetch=430283+0+/usr/local/www/db/text/2009/freebsd-questions/20090329.freebsd-questions and later updated (without apparent change in behavior) to 0182 http://downloadmirror.intel.com/17694/eng/LF_0182_ReleaseNotes.pdf After this, I went back to confirming that 7.2-RELEASE on AMD64 would boot the machine properly on an MBR-based setup on the same physical drive and SATA channel (it does), and then just trying to get GPT-boot to work. Installs are from 7.2-RELEASE AMD64 DVD, as is the "Fixit" environment. I've tried several different approaches, using both gpt and gpart, none of which seem to be able to boot the system. Bizzarely enough, if I do try to boot the GPT disk, with a functional, bootable MBR-based system either on the PATA or on a USB stick, that drive is also no longer bootable. I've tried the approaches outlined by * [GUID] GPT howto -- https://forums.freebsd.org/showthread.php?t=1305 (gpt-based) * http://m8d.de/news/freebsd-on-gpt.php (gpart-based) and the suggestions that gpart should be used instead of gpt in http://forums.freebsd.org/showthread.php?t=1196 by "richardpl" Any suggestions as to how to resolve this (or at least debug it) would be welcome. Thanks! Jeff Not shown are the 'gpart show' commands and responses to determine the next starting offset, as well as a few ls and related commands to make sure I was in the right place. Fixit# df -h Filesystem Size Used Avail Capacity Mounted on /dev/md0 3.7M 2.8M 954K 75% / devfs 1.0K 1.0K 0B 100% /dev /dev/acd0 2.3G 2.3G 0B 100% /dist /dev/da0s1 15G 1.0M 15G 0% /corsair Fixit# gpart show ad4 gpart: No such geom: ad4. Fixit# sysctl kern.geom.debugflags kern.geom.debugflags: 0 Fixit# sysctl kern.geom.debugflags=17 kern.geom.debugflags: 0 -> 17 Fixit# dd if=/dev/zero of=/dev/ad4 bs=512 count=1024 1024+0 records in 1024+0 records out 524288 bytes transferred in 0.819502 secs (639764 bytes/sec) Fixit# gpart show ad4 gpart: No such geom: ad4. Fixit# gpart create -s GPT ad4 ad4 created Fixit# gpart add -b 34 -s 128 -t freebsd-boot ad4 ad4p1 added Fixit# gpart add -b 162 -s 2097152 -t freebsd-ufs ad4 ad4p2 added Fixit# gpart add -b 2097314 -s 8388608 -t freebsd-swap ad4 ad4p3 added Fixit# gpart add -b 10485922 -s 12582912 -t freebsd-ufs ad4 ad4p4 added Fixit# gpart add -b 23068834 -s 12582912 -t freebsd-ufs ad4 ad4p5 added Fixit# gpart add -b 35651746 -s 23068672 -t freebsd-ufs ad4 ad4p6 added Fixit# gpart add -b 58720418 -s 23068672 -t freebsd-ufs ad4 ad4p7 added Fixit# cd /dist/boot Fixit# gpart bootcode -b /dist/boot/pmbr ad4 ad4 has bootcode Fixit# gpart show ad4 => 34 976773101 ad4 GPT (466G) 34 128 1 freebsd-boot (64K) 162 2097152 2 freebsd-ufs (1.0G) 2097314 8388608 3 freebsd-swap (4.0G) 10485922 12582912 4 freebsd-ufs (6.0G) 23068834 12582912 5 freebsd-ufs (6.0G) 35651746 23068672 6 freebsd-ufs (11G) 58720418 23068672 7 freebsd-ufs (11G) 81789090 894984045 - free - (427G) Fixit# gpt show ad4 start size index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 34 128 1 GPT part - FreeBSD boot 162 2097152 2 GPT part - FreeBSD UFS/UFS2 2097314 8388608 3 GPT part - FreeBSD swap 10485922 12582912 4 GPT part - FreeBSD UFS/UFS2 23068834 12582912 5 GPT part - FreeBSD UFS/UFS2 35651746 23068672 6 GPT part - FreeBSD UFS/UFS2 58720418 23068672 7 GPT part - FreeBSD UFS/UFS2 81789090 894984045 976773135 32 Sec GPT table 976773167 1 Sec GPT header Fixit# gpart bootcode -p /dist/boot/gptboot -i 1 ad4 Fixit# newfs -L root /dev/ad4p2 Fixit# newfs -UL var /dev/ad4p4 Fixit# newfs -UL tmp /dev/ad4p5 Fixit# newfs -UL usr /dev/ad4p6 Fixit# newfs -UL vartmp /dev/ad4p7 Fixit# mount /dev/ad4p2 /mnt Fixit# cd /mnt Fixit# mkdir var tmp usr Fixit# mount /dev/ad4p4 var Fixit# mount /dev/ad4p5 tmp Fixit# mount /dev/ad4p6 usr Fixit# mkdir var/tmp Fixit# mount /dev/ad4p7 var/tmp Fixit# df -h Filesystem Size Used Avail Capacity Mounted on /dev/md0 3.7M 2.8M 954K 75% / devfs 1.0K 1.0K 0B 100% /dev /dev/acd0 2.3G 2.3G 0B 100% /dist /dev/da0s1 15G 1.1M 15G 0% /corsair /dev/ad4p2 989M 10K 910M 0% /mnt /dev/ad4p4 5.8G 6.0K 5.3G 0% /mnt/var /dev/ad4p5 5.8G 4.0K 5.3G 0% /mnt/tmp /dev/ad4p6 11G 4.0K 9.8G 0% /mnt/usr /dev/ad4p7 11G 4.0K 9.8G 0% /mnt/var/tmp Fixit# cd /dist Fixit# cd 7.2-RELEASE Fixit# cd base Fixit# export DESTDIR='/mnt' Fixit# ./install.sh You are about to extract the base distribution into /mnt - are you SURE you want to do this over your installed system (y/n)? y Fixit# cd ../kernels Fixit# ./install.sh GENERIC Fixit# cd /mnt/boot Fixit# cp -rp GENERIC/ kernel Fixit# diff -r GENERIC kernel Fixit# exit Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-RELEASE #0: Fri May 1 07:18:07 UTC 2009 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Atom(TM) CPU 330 @ 1.60GHz (1618.36-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106c2 Stepping = 2 Features=0xbfe9fbff Features2=0x40e31d> AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 Logical CPUs per core: 2 usable memory = 2120077312 (2021 MB) avail memory = 2044051456 (1949 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP/HT): APIC ID: 3 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x20e0-0x20e7 mem 0x90200000-0x9027ffff,0x80000000-0x8fffffff,0x90280000-0x902bffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7932k stolen memory agp0: aperture size is 256M pci0: at device 27.0 (no driver attached) pcib1: at device 28.0 on pci0 pci1: on pcib1 re0: port 0x1000-0x10ff mem 0x90100000-0x90100fff,0x90000000-0x9000ffff irq 16 at device 0.0 on pci1 re0: Using 1 MSI messages re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00400000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1c:c0:cd:99:9c re0: [FILTER] pcib2: at device 28.2 on pci0 pci2: on pcib2 pcib3: at device 28.3 on pci0 pci3: on pcib3 uhci0: port 0x2080-0x209f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x2060-0x207f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x2040-0x205f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x2020-0x203f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0x902c4000-0x902c43ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered umass0: on uhub4 pcib4: at device 30.0 on pci0 pci4: on pcib4 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x20b0-0x20bf irq 18 at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] atapci1: port 0x20c8-0x20cf,0x20ec-0x20ef,0x20c0-0x20c7,0x20e8-0x20eb,0x20a0-0x20af irq 19 at device 31.2 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] pci0: at device 31.3 (no driver attached) ppc0: port 0x378-0x37f,0x778-0x77f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] cpu0: on acpi0 p4tcc0: on cpu0 cpu1: on acpi0 p4tcc1: on cpu1 cpu2: on acpi0 p4tcc2: on cpu2 cpu3: on acpi0 p4tcc3: on cpu3 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec md0: Preloaded image 4194304 bytes at 0xffffffff80cd23e0 GEOM_LABEL: Label for provider md0 is ufsid/49faae8a8342179f. acd0: DVDR at ata0-slave UDMA33 ad4: 476940MB at ata2-master SATA150 GEOM_LABEL: Label for provider acd0 is iso9660/FreeBSD_Install. SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 15424MB (31588352 512 byte sectors: 255H 63S/T 1966C) GEOM_LABEL: Label for provider da0s1 is msdosfs/CORSAIR16G. Trying to mount root from ufs:/dev/md0 GEOM_LABEL: Label ufsid/49faae8a8342179f removed. GEOM_LABEL: Label msdosfs/CORSAIR16G removed. From listat at apz.fi Tue Jun 9 19:45:56 2009 From: listat at apz.fi (=?ISO-8859-1?Q?Ari_Sovij=E4rvi?=) Date: Tue Jun 9 19:46:03 2009 Subject: Geli and EVP_camellia_256_cbc Message-ID: <4A2EB780.2020607@apz.fi> Hi folks. I tried to set up an encypted swap partition with Geli as described in the handbook. However, during the reboot, the encswap-script caused the following error: geli: Cannot open library: /lib/geom/geom_eli.so: Undefined symbol "EVP_camellia_256_cbc". The system is: FreeBSD 7.2-RELEASE (RAINFALL) #0: Tue Jun 9 15:31:12 EEST 2009 sparc64 I originally ran into this problem with 7.1, and I upgraded to 7.2 today to see if the problem was fixed in that. TIA for any clues for solving this one :) -- Ari Sovij?rvi From bo.coopci at i-waihui.com Wed Jun 10 07:57:51 2009 From: bo.coopci at i-waihui.com (cooper) Date: Wed Jun 10 07:58:12 2009 Subject: how is multipath information stored Message-ID: <4A2F6778.4050200@gmail.com> Hi, folks. I wander where FreeBSD saves the information about the geom, for instance which underlying devices are used to construct a multipath label and what's the name of the label. In another word, how does the system restore the multipathes which I configured before the last reboot during the start up phase. From dan.naumov at gmail.com Wed Jun 10 08:16:50 2009 From: dan.naumov at gmail.com (Dan Naumov) Date: Wed Jun 10 08:16:56 2009 Subject: how is multipath information stored In-Reply-To: <4A2F6778.4050200@gmail.com> References: <4A2F6778.4050200@gmail.com> Message-ID: This is a really wild guess (so correct me if I am wrong), but I would guess this information is stored as metadata inside the geom provider after you have initialized it, so on boot, GEOM searches for any providers attached, reads their metadata and loads them accordingly. What has me curious though is what happens if you, for example, swap a few disks around so your (for example) /dev/ad1 "this boot" isn't the same as the /dev/ad1 the previous time. Are GEOM labels unique? If they are, it is obviously possible for GEOM to transparently restore your configuration after you have changed your disk configuration. But if they aren't, it could be quite a pain in certain situations... - Dan Naumov 2009/6/10 cooper : > Hi, folks. > I wander where FreeBSD saves the information about the geom, for > instance which underlying devices are used to construct a multipath > label and what's the name of the label. In another word, how does the > system restore the multipathes which I configured before the last reboot > during the start up phase. > _______________________________________________ > freebsd-geom@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-geom > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" > From ivoras at freebsd.org Wed Jun 10 09:12:11 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Jun 10 09:12:17 2009 Subject: Geli and EVP_camellia_256_cbc In-Reply-To: <4A2EB780.2020607@apz.fi> References: <4A2EB780.2020607@apz.fi> Message-ID: Ari Sovij?rvi wrote: > Hi folks. > > I tried to set up an encypted swap partition with Geli as described in > the handbook. However, during the reboot, the encswap-script caused the > following error: > > geli: Cannot open library: /lib/geom/geom_eli.so: Undefined symbol > "EVP_camellia_256_cbc". > > The system is: > FreeBSD 7.2-RELEASE (RAINFALL) #0: Tue Jun 9 15:31:12 EEST 2009 sparc64 > > I originally ran into this problem with 7.1, and I upgraded to 7.2 today > to see if the problem was fixed in that. > > TIA for any clues for solving this one :) Possibly your world is not in sync. /usr/lib> strings libssl.so | grep EVP EVP_des_cbc EVP_add_cipher EVP_des_ede3_cbc EVP_rc4 EVP_rc2_cbc EVP_aes_128_cbc EVP_aes_192_cbc EVP_aes_256_cbc EVP_camellia_128_cbc EVP_camellia_256_cbc From listat at apz.fi Thu Jun 11 17:14:17 2009 From: listat at apz.fi (=?ISO-8859-1?Q?Ari_Sovij=E4rvi?=) Date: Thu Jun 11 17:14:24 2009 Subject: Geli and EVP_camellia_256_cbc Message-ID: <4A313B5E.3040300@apz.fi> Ivan Voras wrote: > Possibly your world is not in sync. > /usr/lib> strings libssl.so | grep EVP > EVP_des_cbc > EVP_add_cipher > EVP_des_ede3_cbc > EVP_rc4 > EVP_rc2_cbc > EVP_aes_128_cbc > EVP_aes_192_cbc > EVP_aes_256_cbc > EVP_camellia_128_cbc > EVP_camellia_256_cbc That command does not list camellia, as it's disabled in sparc64 builds. Looking at openssl's source (especially crypto/openssl/crypto/evp/e_camellia.c), there's a condition not to build camellia if OPENSSL_NO_CAMELLIA is defined. In opensslconf-sparc64.h again that gets set, but that condition isn't in geom, so apparently in sparc64 geli is broken to my understanding. Could someone with more in-depth knowledge about geli verify this finding, or alternatively try this on a sparc64 system? I have couple of the systems online, one with 7.1 and the other with 7.2, both seem to behave the same way. I've also have one i386 7.2 system (from the same source), and it seems to work. -- Ari Sovij?rvi From jeff+freebsd at wagsky.com Fri Jun 12 18:11:23 2009 From: jeff+freebsd at wagsky.com (Jeff Kletsky) Date: Fri Jun 12 18:11:29 2009 Subject: GPT fails to be recognized by BIOS boot, Intel Atom 330 D945GCLF2, 7.2-RELEASE In-Reply-To: <4A2D6652.4050008@wagsky.com> References: <4A2D6652.4050008@wagsky.com> Message-ID: <4A329A44.9060505@wagsky.com> Jeff Kletsky wrote: > After getting what I thought to be a good configuration built up and > installed on, it failed to boot. I confirmed that I could build a > MBR-based system on the same drive on the same platform > (Intel Atom 330 on Intel D945GCLF2 motherboard, 2 GB RAM, > BIOS LF94510J.86A.0140.2008.1231.0012, later updated to > BIOS LF94510J.86A.0182.2008.1231.0012) > > [...] > > I've tried several different approaches, using both gpt and gpart, > none of which seem to be able to boot the system. Bizzarely enough, if > I do try to boot the GPT disk, with a functional, bootable MBR-based > system > either on the PATA or on a USB stick, that drive is also no longer > bootable. > The problem appears to be with the MB and BIOS (consistent on three different boards). For some set of reasonable BIOS settings, the machine will enter a state where it will not recognize anything I've tried but a CD/DVD as bootable (even though they boot other systems). I've since confirmed that I can create bootable gjournal on gmirror on GPT via gpart for AMD64. Intel not supplying help until I use 'approved" memory (I'm using a Corsair 2G stick that they've only tested the 1G and below versions). http://communities.intel.com/message/25506 contains pointers to several Intel forums issues, as well as the OCZ forums where this has been deeply explored. From dan.naumov at gmail.com Fri Jun 12 20:44:24 2009 From: dan.naumov at gmail.com (Dan Naumov) Date: Fri Jun 12 20:44:31 2009 Subject: GPT fails to be recognized by BIOS boot, Intel Atom 330 D945GCLF2, 7.2-RELEASE In-Reply-To: <4A329A44.9060505@wagsky.com> References: <4A2D6652.4050008@wagsky.com> <4A329A44.9060505@wagsky.com> Message-ID: Try the following: BIOS Setting BIOS_POWER_After Power Falure = - Dan Naumov On Fri, Jun 12, 2009 at 9:11 PM, Jeff Kletsky wrote: > Jeff Kletsky wrote: >> >> After getting what I thought to be a good configuration built up and >> installed on, it failed to boot. I confirmed that I could build a >> MBR-based system on the same drive on the same platform >> (Intel Atom 330 on Intel D945GCLF2 motherboard, 2 GB RAM, >> BIOS LF94510J.86A.0140.2008.1231.0012, later updated to >> BIOS LF94510J.86A.0182.2008.1231.0012) >> >> [...] >> >> I've tried several different approaches, using both gpt and gpart, >> none of which seem to be able to boot the system. Bizzarely enough, if >> I do try to boot the GPT disk, with a functional, bootable MBR-based >> system >> either on the PATA or on a USB stick, that drive is also no longer >> bootable. >> > > The problem appears to be with the MB and BIOS (consistent on three > different boards). For some set of reasonable BIOS settings, the machine > will enter a state where it will not recognize anything I've tried but a > CD/DVD as bootable (even though they boot other systems). > > I've since confirmed that I can create bootable gjournal on gmirror on GPT > via gpart for AMD64. > > Intel not supplying help until I use 'approved" memory (I'm using a Corsair > 2G stick that they've only tested the 1G and below versions). > > http://communities.intel.com/message/25506 contains pointers to several > Intel forums issues, as well as the OCZ forums where this has been deeply > explored. > > > _______________________________________________ > freebsd-geom@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-geom > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" > From dfilter at FreeBSD.ORG Sat Jun 13 00:30:04 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Sat Jun 13 00:30:10 2009 Subject: bin/128398: commit references a PR Message-ID: <200906130030.n5D0U3A2053304@freefall.freebsd.org> The following reply was made to PR bin/128398; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: bin/128398: commit references a PR Date: Sat, 13 Jun 2009 00:27:18 +0000 (UTC) Author: ivoras Date: Sat Jun 13 00:27:03 2009 New Revision: 194092 URL: http://svn.freebsd.org/changeset/base/194092 Log: Add support for labels derived from GPT metadata. Approved by: gnn (mentor) Reviewed by: pjd PR: 128398 Submitted by: Marius Nuennerich < marius at nuenneri.ch > Added: head/sys/geom/label/g_label_gpt.c (contents, props changed) Modified: head/sbin/geom/class/label/glabel.8 head/sys/conf/files head/sys/geom/label/g_label.c head/sys/geom/label/g_label.h Modified: head/sbin/geom/class/label/glabel.8 ============================================================================== --- head/sbin/geom/class/label/glabel.8 Sat Jun 13 00:13:44 2009 (r194091) +++ head/sbin/geom/class/label/glabel.8 Sat Jun 13 00:27:03 2009 (r194092) @@ -1,4 +1,5 @@ .\" Copyright (c) 2004-2005 Pawel Jakub Dawidek +.\" Copyright (c) 2008-2009 Ivan Voras .\" All rights reserved. .\" .\" Redistribution and use in source and binary forms, with or without @@ -24,7 +25,7 @@ .\" .\" $FreeBSD$ .\" -.Dd July 2, 2004 +.Dd June 13, 2009 .Dt GLABEL 8 .Os .Sh NAME @@ -119,7 +120,18 @@ NTFS (directory .Pa /dev/ntfs/ ) . .El .Pp -Non file-system labels are created in the directory +Support for partition metadata is implemented for: +.Pp +.Bl -bullet -offset indent -compact +.It +GPT labels (directory +.Pa /dev/gpt/ ) . +.It +GPT UUIDs (directory +.Pa /dev/gptid/ ) . +.El +.Pp +Generic labels are created in the directory .Pa /dev/label/ . .Pp The first argument to Modified: head/sys/conf/files ============================================================================== --- head/sys/conf/files Sat Jun 13 00:13:44 2009 (r194091) +++ head/sys/conf/files Sat Jun 13 00:27:03 2009 (r194092) @@ -1852,6 +1852,7 @@ geom/label/g_label_msdosfs.c optional ge geom/label/g_label_ntfs.c optional geom_label geom/label/g_label_reiserfs.c optional geom_label geom/label/g_label_ufs.c optional geom_label +geom/label/g_label_gpt.c optional geom_label geom/linux_lvm/g_linux_lvm.c optional geom_linux_lvm geom/mirror/g_mirror.c optional geom_mirror geom/mirror/g_mirror_ctl.c optional geom_mirror Modified: head/sys/geom/label/g_label.c ============================================================================== --- head/sys/geom/label/g_label.c Sat Jun 13 00:13:44 2009 (r194091) +++ head/sys/geom/label/g_label.c Sat Jun 13 00:27:03 2009 (r194092) @@ -84,6 +84,8 @@ const struct g_label_desc *g_labels[] = &g_label_ext2fs, &g_label_reiserfs, &g_label_ntfs, + &g_label_gpt, + &g_label_gpt_uuid, NULL }; Modified: head/sys/geom/label/g_label.h ============================================================================== --- head/sys/geom/label/g_label.h Sat Jun 13 00:13:44 2009 (r194091) +++ head/sys/geom/label/g_label.h Sat Jun 13 00:27:03 2009 (r194092) @@ -71,6 +71,8 @@ extern const struct g_label_desc g_label extern const struct g_label_desc g_label_ext2fs; extern const struct g_label_desc g_label_reiserfs; extern const struct g_label_desc g_label_ntfs; +extern const struct g_label_desc g_label_gpt; +extern const struct g_label_desc g_label_gpt_uuid; #endif /* _KERNEL */ struct g_label_metadata { Added: head/sys/geom/label/g_label_gpt.c ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/sys/geom/label/g_label_gpt.c Sat Jun 13 00:27:03 2009 (r194092) @@ -0,0 +1,164 @@ +/*- + * Copyright (c) 2008 Marius Nuennerich + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#define PART_CLASS_NAME "PART" +#define SCHEME_NAME "GPT" + +#define G_LABEL_GPT_VOLUME_DIR "gpt" +#define G_LABEL_GPT_ID_DIR "gptid" + +/* also defined in geom/part/g_part_gpt.c */ +struct g_part_gpt_entry { + struct g_part_entry base; + struct gpt_ent ent; +}; + +/* shamelessly stolen from g_part_gpt.c */ +static void +sbuf_nprintf_utf16(struct sbuf *sb, uint16_t *str, size_t len) +{ + u_int bo; + uint32_t ch; + uint16_t c; + + bo = LITTLE_ENDIAN; /* GPT is little-endian */ + while (len > 0 && *str != 0) { + ch = (bo == BIG_ENDIAN) ? be16toh(*str) : le16toh(*str); + str++, len--; + if ((ch & 0xf800) == 0xd800) { + if (len > 0) { + c = (bo == BIG_ENDIAN) ? be16toh(*str) + : le16toh(*str); + str++, len--; + } else + c = 0xfffd; + if ((ch & 0x400) == 0 && (c & 0xfc00) == 0xdc00) { + ch = ((ch & 0x3ff) << 10) + (c & 0x3ff); + ch += 0x10000; + } else + ch = 0xfffd; + } else if (ch == 0xfffe) { /* BOM (U+FEFF) swapped. */ + bo = (bo == BIG_ENDIAN) ? LITTLE_ENDIAN : BIG_ENDIAN; + continue; + } else if (ch == 0xfeff) /* BOM (U+FEFF) unswapped. */ + continue; + + /* Write the Unicode character in UTF-8 */ + if (ch < 0x80) + sbuf_printf(sb, "%c", ch); + else if (ch < 0x800) + sbuf_printf(sb, "%c%c", 0xc0 | (ch >> 6), + 0x80 | (ch & 0x3f)); + else if (ch < 0x10000) + sbuf_printf(sb, "%c%c%c", 0xe0 | (ch >> 12), + 0x80 | ((ch >> 6) & 0x3f), 0x80 | (ch & 0x3f)); + else if (ch < 0x200000) + sbuf_printf(sb, "%c%c%c%c", 0xf0 | (ch >> 18), + 0x80 | ((ch >> 12) & 0x3f), + 0x80 | ((ch >> 6) & 0x3f), 0x80 | (ch & 0x3f)); + } +} + +static void +g_label_gpt_taste(struct g_consumer *cp, char *label, size_t size) +{ + struct g_provider *pp; + struct g_part_table *tp; + struct g_part_gpt_entry *part_gpt_entry; + struct sbuf *lbl; + + g_topology_assert_not(); + pp = cp->provider; + tp = (struct g_part_table *)pp->geom->softc; + label[0] = '\0'; + + /* We taste only partitions from GPART */ + if (strncmp(pp->geom->class->name, PART_CLASS_NAME, sizeof(PART_CLASS_NAME))) + return; + /* and only GPT */ + if (strncmp(tp->gpt_scheme->name, SCHEME_NAME, sizeof(SCHEME_NAME))) + return; + + part_gpt_entry = (struct g_part_gpt_entry *)pp->private; + + /* + * create sbuf with biggest possible size + * we need max. 4 bytes for every 2-byte utf16 char + */ + lbl = sbuf_new(NULL, NULL, sizeof(part_gpt_entry->ent.ent_name) << 1, SBUF_FIXEDLEN); + /* size ist the number of characters, not bytes */ + sbuf_nprintf_utf16(lbl, part_gpt_entry->ent.ent_name, sizeof(part_gpt_entry->ent.ent_name) >> 1); + sbuf_finish(lbl); + strlcpy(label, sbuf_data(lbl), size); + sbuf_delete(lbl); +} + +static void +g_label_gpt_uuid_taste(struct g_consumer *cp, char *label, size_t size) +{ + struct g_provider *pp; + struct g_part_table *tp; + struct g_part_gpt_entry *part_gpt_entry; + + g_topology_assert_not(); + pp = cp->provider; + tp = (struct g_part_table *)pp->geom->softc; + label[0] = '\0'; + + /* we taste only partitions from GPART */ + if (strncmp(pp->geom->class->name, PART_CLASS_NAME, sizeof(PART_CLASS_NAME))) + return; + /* and only GPT */ + if (strncmp(tp->gpt_scheme->name, SCHEME_NAME, sizeof(SCHEME_NAME))) + return; + + part_gpt_entry = (struct g_part_gpt_entry *)pp->private; + snprintf_uuid(label, size, &part_gpt_entry->ent.ent_uuid); +} + +const struct g_label_desc g_label_gpt = { + .ld_taste = g_label_gpt_taste, + .ld_dir = G_LABEL_GPT_VOLUME_DIR +}; + +const struct g_label_desc g_label_gpt_uuid = { + .ld_taste = g_label_gpt_uuid_taste, + .ld_dir = G_LABEL_GPT_ID_DIR +}; _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From dan.naumov at gmail.com Sun Jun 14 16:16:24 2009 From: dan.naumov at gmail.com (Dan Naumov) Date: Sun Jun 14 16:16:35 2009 Subject: Does this disk/filesystem layout look sane to you? Message-ID: Hello list. I just wanted to have an extra pair (or a dozen) of eyes look this configuration over before I commit to it (tested it in VMWare just in case, it works, so I am considering doing this on real hardware soon). I drew a nice diagram: http://www.pastebin.ca/1460089 Since it doesnt show on the diagram, let me clarify that the geom mirror consumers as well as the vdevz for ZFS RAIDZ are going to be partitions (raw disk => full disk slice => swap partition | mirror provider partition | zfs vdev partition | unused. Is there any actual downside to having a 5-way mirror vs a 2-way or a 3-way one? - Sincerely, Dan Naumov From bugmaster at FreeBSD.org Mon Jun 15 11:06:55 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 15 11:08:07 2009 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200906151106.n5FB6sIC076911@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/134922 geom [gmirror] [panic] kernel panic when use fdisk on disk o kern/134113 geom [geli] Problem setting secondary GELI key o kern/134044 geom [geom] gmirror(8) overwrites fs with stale data from r o kern/133931 geom [geli] [request] intentionally wrong password to destr o bin/132845 geom [geom] [patch] ggated(8) does not close files opened a o kern/132273 geom glabel(8): [patch] failing on journaled partition o kern/132242 geom [gmirror] gmirror.ko fails to fully initialize o kern/131353 geom [geom] gjournal(8) kernel lock o kern/131037 geom [geli] Unable to create disklabel on .eli-Device p docs/130548 geom [patch] gjournal(8) man page is missing sysctls o kern/130528 geom gjournal fsck during boot o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid o bin/128398 geom [patch] glabel(8): teach geom_label to recognise gpt l f kern/128276 geom [gmirror] machine lock up when gmirror module is used o kern/126902 geom [geom] geom_label: kernel panic during install boot o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s o kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin o kern/124130 geom [gmirror] [usb] gmirror fails to start usb devices tha o kern/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123630 geom [patch] [gmirror] gmirror doesnt allow the original dr o kern/123122 geom [geom] GEOM / gjournal kernel lock o kern/122738 geom [geom] gmirror list "losts consumers" after gmirror de f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/121481 geom [gmirror] data rot on disk with gmirror o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120231 geom [geom] GEOM_CONCAT error adding second drive o kern/120091 geom [geom] [geli] [gjournal] geli does not prompt for pass o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis o kern/120021 geom [geom] [panic] net-p2p/qbittorrent crashes system when o kern/119743 geom [geom] geom label for cds is keeped after dismount and p kern/116896 geom [geom] [patch] Typo in a kassert in GEOM o kern/115856 geom [geli] ZFS thought it was degraded when it should have o kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113885 geom [gmirror] [patch] improved gmirror balance algorithm o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back p bin/110705 geom gmirror(8) control utility does not exit with correct o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o bin/90093 geom fdisk(8) incapable of altering in-core geometry a kern/89660 geom [vinum] [patch] [panic] due to g_malloc returning null o kern/89546 geom [geom] GEOM error s kern/89102 geom [geom] [panic] panic when forced unmount FS from unplu o kern/88601 geom [geli] geli cause kernel panic under heavy disk usage o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu o bin/81779 geom misleading error messages in geom(8) utilities. o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o bin/78131 geom gbde(8) "destroy" not working. s kern/73177 geom kldload geom_* causes panic due to memory exhaustion 61 problems total. From peter at vk2pj.dyndns.org Tue Jun 16 19:05:08 2009 From: peter at vk2pj.dyndns.org (Peter Jeremy) Date: Tue Jun 16 19:05:15 2009 Subject: Does this disk/filesystem layout look sane to you? In-Reply-To: References: Message-ID: <20090616185221.GI9529@server.vk2pj.dyndns.org> On 2009-Jun-14 19:16:22 +0300, Dan Naumov wrote: >Is there any actual downside to having a 5-way mirror vs a 2-way or a 3-way one? Only write performance to the UFS root filesystem. I run a system using a similar approach (though across 3 disks). My only suggestion would be that instead of a single 5-way mirrored root, you have a 2- or 3-way mirrored root and an off-line root backup using the remaining disks - if you accidently trash your active root, you can just boot off one of the other disks to recover. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090616/d54e08d6/attachment.pgp From linimon at FreeBSD.org Sun Jun 21 05:07:42 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Jun 21 05:07:48 2009 Subject: kern/135874: [geom] [patch] geom_linux_lvm misses newer fedora defaults Message-ID: <200906210507.n5L57fN5062292@freefall.freebsd.org> Old Synopsis: Geom_linux_lvm misses newer fedora defaults New Synopsis: [geom] [patch] geom_linux_lvm misses newer fedora defaults Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jun 21 05:07:14 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=135874 From ulf.lilleengen at gmail.com Sun Jun 21 20:14:57 2009 From: ulf.lilleengen at gmail.com (Ulf Lilleengen) Date: Sun Jun 21 20:15:03 2009 Subject: kern/135874: [geom] [patch] geom_linux_lvm misses newer fedora defaults In-Reply-To: <200906210507.n5L57fN5062292@freefall.freebsd.org> References: <200906210507.n5L57fN5062292@freefall.freebsd.org> Message-ID: <200906212145.35524.lulf@freebsd.org> On Sunday 21 June 2009 07:07:41 linimon@freebsd.org wrote: > Old Synopsis: Geom_linux_lvm misses newer fedora defaults > New Synopsis: [geom] [patch] geom_linux_lvm misses newer fedora defaults > > Responsible-Changed-From-To: freebsd-bugs->freebsd-geom > Responsible-Changed-By: linimon > Responsible-Changed-When: Sun Jun 21 05:07:14 UTC 2009 > Responsible-Changed-Why: > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=135874 > _______________________________________________ > freebsd-geom@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-geom > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" Hi, I took a look at the LVM2 source code to see what is defined as a valid volume name, and came up with a patch[1]. If theres not any protest against it, i'll commit it. [1] http://people.freebsd.org/~lulf/patches/llvm_validate.diff -- Ulf Lilleengen From ulf.lilleengen at gmail.com Sun Jun 21 20:20:06 2009 From: ulf.lilleengen at gmail.com (Ulf Lilleengen) Date: Sun Jun 21 20:20:13 2009 Subject: kern/135874: [geom] [patch] geom_linux_lvm misses newer fedora defaults Message-ID: <200906212020.n5LKK6Hr092802@freefall.freebsd.org> The following reply was made to PR kern/135874; it has been noted by GNATS. From: Ulf Lilleengen To: freebsd-geom@freebsd.org Cc: bug-followup@freebsd.org, thompsa@freebsd.org Subject: Re: kern/135874: [geom] [patch] geom_linux_lvm misses newer fedora defaults Date: Sun, 21 Jun 2009 21:45:35 +0200 On Sunday 21 June 2009 07:07:41 linimon@freebsd.org wrote: > Old Synopsis: Geom_linux_lvm misses newer fedora defaults > New Synopsis: [geom] [patch] geom_linux_lvm misses newer fedora defaults > > Responsible-Changed-From-To: freebsd-bugs->freebsd-geom > Responsible-Changed-By: linimon > Responsible-Changed-When: Sun Jun 21 05:07:14 UTC 2009 > Responsible-Changed-Why: > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=135874 > _______________________________________________ > freebsd-geom@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-geom > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" Hi, I took a look at the LVM2 source code to see what is defined as a valid volume name, and came up with a patch[1]. If theres not any protest against it, i'll commit it. [1] http://people.freebsd.org/~lulf/patches/llvm_validate.diff -- Ulf Lilleengen From ulf.lilleengen at gmail.com Sun Jun 21 20:40:04 2009 From: ulf.lilleengen at gmail.com (Ulf Lilleengen) Date: Sun Jun 21 20:40:12 2009 Subject: kern/135874: [geom] [patch] geom_linux_lvm misses newer fedora defaults Message-ID: <200906212040.n5LKe4Wg009928@freefall.freebsd.org> The following reply was made to PR kern/135874; it has been noted by GNATS. From: Ulf Lilleengen To: bug-followup@freebsd.org Cc: Subject: Re: kern/135874: [geom] [patch] geom_linux_lvm misses newer fedora defaults Date: Sun, 21 Jun 2009 22:32:17 +0200 On Sunday 21 June 2009 22:20:06 Ulf Lilleengen wrote: > The following reply was made to PR kern/135874; it has been noted by GNATS. > > From: Ulf Lilleengen > To: freebsd-geom@freebsd.org > Cc: bug-followup@freebsd.org, > thompsa@freebsd.org > Subject: Re: kern/135874: [geom] [patch] geom_linux_lvm misses newer fedora > defaults Date: Sun, 21 Jun 2009 21:45:35 +0200 > > On Sunday 21 June 2009 07:07:41 linimon@freebsd.org wrote: > > Old Synopsis: Geom_linux_lvm misses newer fedora defaults > > New Synopsis: [geom] [patch] geom_linux_lvm misses newer fedora defaults > > > > Responsible-Changed-From-To: freebsd-bugs->freebsd-geom > > Responsible-Changed-By: linimon > > Responsible-Changed-When: Sun Jun 21 05:07:14 UTC 2009 > > Responsible-Changed-Why: > > Over to maintainer(s). > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=135874 > > _______________________________________________ > > freebsd-geom@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-geom > > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" > > Hi, > > I took a look at the LVM2 source code to see what is defined as a valid > volume name, and came up with a patch[1]. If theres not any protest against > it, i'll commit it. > > [1] http://people.freebsd.org/~lulf/patches/llvm_validate.diff > -- Updated patch: http://people.freebsd.org/~lulf/patches/llvm_validate2.diff -- Ulf Lilleengen From linimon at FreeBSD.org Mon Jun 22 00:44:21 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Jun 22 00:44:32 2009 Subject: kern/135898: [geom] Severe filesystem corruption - large files or large filesystems Message-ID: <200906220044.n5M0iKGk002098@freefall.freebsd.org> Old Synopsis: Severe filesystem corruption - large files or large filesystems New Synopsis: [geom] Severe filesystem corruption - large files or large filesystems Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jun 22 00:43:05 UTC 2009 Responsible-Changed-Why: I'm going to take a guess and assign this to the geom mailing list. http://www.freebsd.org/cgi/query-pr.cgi?pr=135898 From bugmaster at FreeBSD.org Mon Jun 22 11:06:56 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 22 11:08:07 2009 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200906221106.n5MB6sOY018022@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/135898 geom [geom] Severe filesystem corruption - large files or l o kern/135874 geom [geom] [patch] geom_linux_lvm misses newer fedora defa o kern/134922 geom [gmirror] [panic] kernel panic when use fdisk on disk o kern/134113 geom [geli] Problem setting secondary GELI key o kern/134044 geom [geom] gmirror(8) overwrites fs with stale data from r o kern/133931 geom [geli] [request] intentionally wrong password to destr o bin/132845 geom [geom] [patch] ggated(8) does not close files opened a o kern/132273 geom glabel(8): [patch] failing on journaled partition o kern/132242 geom [gmirror] gmirror.ko fails to fully initialize o kern/131353 geom [geom] gjournal(8) kernel lock o kern/131037 geom [geli] Unable to create disklabel on .eli-Device p docs/130548 geom [patch] gjournal(8) man page is missing sysctls o kern/130528 geom gjournal fsck during boot o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid o bin/128398 geom [patch] glabel(8): teach geom_label to recognise gpt l f kern/128276 geom [gmirror] machine lock up when gmirror module is used o kern/126902 geom [geom] geom_label: kernel panic during install boot o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s o kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin o kern/124130 geom [gmirror] [usb] gmirror fails to start usb devices tha o kern/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123630 geom [patch] [gmirror] gmirror doesnt allow the original dr o kern/123122 geom [geom] GEOM / gjournal kernel lock o kern/122738 geom [geom] gmirror list "losts consumers" after gmirror de f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/121481 geom [gmirror] data rot on disk with gmirror o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120231 geom [geom] GEOM_CONCAT error adding second drive o kern/120091 geom [geom] [geli] [gjournal] geli does not prompt for pass o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis o kern/120021 geom [geom] [panic] net-p2p/qbittorrent crashes system when o kern/119743 geom [geom] geom label for cds is keeped after dismount and p kern/116896 geom [geom] [patch] Typo in a kassert in GEOM o kern/115856 geom [geli] ZFS thought it was degraded when it should have o kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113885 geom [gmirror] [patch] improved gmirror balance algorithm o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back p bin/110705 geom gmirror(8) control utility does not exit with correct o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o bin/90093 geom fdisk(8) incapable of altering in-core geometry a kern/89660 geom [vinum] [patch] [panic] due to g_malloc returning null o kern/89546 geom [geom] GEOM error s kern/89102 geom [geom] [panic] panic when forced unmount FS from unplu o kern/88601 geom [geli] geli cause kernel panic under heavy disk usage o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu o bin/81779 geom misleading error messages in geom(8) utilities. o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o bin/78131 geom gbde(8) "destroy" not working. s kern/73177 geom kldload geom_* causes panic due to memory exhaustion 63 problems total. From dan.naumov at gmail.com Wed Jun 24 20:27:33 2009 From: dan.naumov at gmail.com (Dan Naumov) Date: Wed Jun 24 20:27:45 2009 Subject: read benchmarks: ufs/zfs/ext3 raidz/raid5 Message-ID: Another FreeBSD person on a forum I frequent did some read benchmarks on his system: Athlon64 3500+ with 2GB DDR2 SDRAM, a WD 250GB system drive, and 5 Seagate Barracuda 750GB SATA-II data drives. ZFS and UFS testing was done using FreeBSD 7.2-RELEASE amd64, and ext3 testing was done using Ubuntu Server 8.04-LTS amd64. The used disks do not support NCQ, so there is no "NCQ advantage" on the Linux side. Random Access reads, 5MB chunks: http://virtual.tehinterweb.net/livejournal/2009-06-22_zfs_diskperf/zfs-diskperf-untuned-5mb.png Random Access reads, 1MB chunks: http://virtual.tehinterweb.net/livejournal/2009-06-22_zfs_diskperf/zfs-diskperf-untuned-1mb.png Random Access reads, 5MB chunks (big list): http://virtual.tehinterweb.net/livejournal/raid_performance/raid-diskperf-5mb-all.png Here is the original forum discussion thread: http://episteme.arstechnica.com/eve/forums/a/tpc/f/96509133/m/857002910041 Sincerely, - Dan Naumov From dfilter at FreeBSD.ORG Wed Jun 24 22:10:05 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Wed Jun 24 22:10:11 2009 Subject: kern/135874: commit references a PR Message-ID: <200906242210.n5OMA3G8033949@freefall.freebsd.org> The following reply was made to PR kern/135874; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/135874: commit references a PR Date: Wed, 24 Jun 2009 22:09:45 +0000 (UTC) Author: lulf Date: Wed Jun 24 22:09:30 2009 New Revision: 194924 URL: http://svn.freebsd.org/changeset/base/194924 Log: - Apply the same naming rules of LVM names as done in the LVM code itself. PR: kern/135874 Modified: head/sys/geom/linux_lvm/g_linux_lvm.c Modified: head/sys/geom/linux_lvm/g_linux_lvm.c ============================================================================== --- head/sys/geom/linux_lvm/g_linux_lvm.c Wed Jun 24 22:06:56 2009 (r194923) +++ head/sys/geom/linux_lvm/g_linux_lvm.c Wed Jun 24 22:09:30 2009 (r194924) @@ -826,14 +826,6 @@ llvm_md_decode(const u_char *data, struc return (0); } -#define GRAB_NAME(tok, name, len) \ - len = 0; \ - while (tok[len] && (isalpha(tok[len]) || isdigit(tok[len])) && \ - len < G_LLVM_NAMELEN - 1) \ - len++; \ - bcopy(tok, name, len); \ - name[len] = '\0'; - #define GRAB_INT(key, tok1, tok2, v) \ if (tok1 && tok2 && strncmp(tok1, key, sizeof(key)) == 0) { \ v = strtol(tok2, &tok1, 10); \ @@ -864,6 +856,27 @@ llvm_md_decode(const u_char *data, struc break; \ } +static size_t +llvm_grab_name(char *name, const char *tok) +{ + size_t len; + + len = 0; + if (tok == NULL) + return (0); + if (tok[0] == '-') + return (0); + if (strcmp(tok, ".") == 0 || strcmp(tok, "..") == 0) + return (0); + while (tok[len] && (isalpha(tok[len]) || isdigit(tok[len]) || + tok[len] == '.' || tok[len] == '_' || tok[len] == '-' || + tok[len] == '+') && len < G_LLVM_NAMELEN - 1) + len++; + bcopy(tok, name, len); + name[len] = '\0'; + return (len); +} + static int llvm_textconf_decode(u_char *data, int buflen, struct g_llvm_metadata *md) { @@ -872,7 +885,7 @@ llvm_textconf_decode(u_char *data, int b char *tok, *v; char name[G_LLVM_NAMELEN]; char uuid[G_LLVM_UUIDLEN]; - int len; + size_t len; if (buf == NULL || *buf == '\0') return (EINVAL); @@ -880,7 +893,7 @@ llvm_textconf_decode(u_char *data, int b tok = strsep(&buf, "\n"); if (tok == NULL) return (EINVAL); - GRAB_NAME(tok, name, len); + len = llvm_grab_name(name, tok); if (len == 0) return (EINVAL); @@ -970,7 +983,7 @@ llvm_textconf_decode_pv(char **buf, char { struct g_llvm_pv *pv; char *v; - int len; + size_t len; if (*buf == NULL || **buf == '\0') return (EINVAL); @@ -983,7 +996,7 @@ llvm_textconf_decode_pv(char **buf, char len = 0; if (tok == NULL) goto bad; - GRAB_NAME(tok, pv->pv_name, len); + len = llvm_grab_name(pv->pv_name, tok); if (len == 0) goto bad; @@ -1024,7 +1037,7 @@ llvm_textconf_decode_lv(char **buf, char struct g_llvm_lv *lv; struct g_llvm_segment *sg; char *v; - int len; + size_t len; if (*buf == NULL || **buf == '\0') return (EINVAL); @@ -1036,10 +1049,9 @@ llvm_textconf_decode_lv(char **buf, char lv->lv_vg = vg; LIST_INIT(&lv->lv_segs); - len = 0; if (tok == NULL) goto bad; - GRAB_NAME(tok, lv->lv_name, len); + len = llvm_grab_name(lv->lv_name, tok); if (len == 0) goto bad; @@ -1162,7 +1174,6 @@ bad: free(sg, M_GLLVM); return (-1); } -#undef GRAB_NAME #undef GRAB_INT #undef GRAB_STR #undef SPLIT _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From peterjeremy at optushome.com.au Fri Jun 26 07:18:17 2009 From: peterjeremy at optushome.com.au (peterjeremy@optushome.com.au) Date: Fri Jun 26 07:18:29 2009 Subject: read benchmarks: ufs/zfs/ext3 raidz/raid5 In-Reply-To: References: Message-ID: <20090626071812.GA43965@server.vk2pj.dyndns.org> On 2009-Jun-24 23:27:31 +0300, Dan Naumov wrote: >Random Access reads, 5MB chunks: >http://virtual.tehinterweb.net/livejournal/2009-06-22_zfs_diskperf/zfs-diskperf-untuned-5mb.png >Random Access reads, 1MB chunks: >http://virtual.tehinterweb.net/livejournal/2009-06-22_zfs_diskperf/zfs-diskperf-untuned-1mb.png >Random Access reads, 5MB chunks (big list): >http://virtual.tehinterweb.net/livejournal/raid_performance/raid-diskperf-5mb-all.png These benchmarks are all fairly meaningless. As a first order approximation, all I/O to a Unix FS should be writes or you don't have enough RAM for your application. A more meaningful benchmark would check writes or a read/write mix with ~90% writes. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090626/13e4c5b1/attachment.pgp From dan.naumov at gmail.com Fri Jun 26 23:36:56 2009 From: dan.naumov at gmail.com (Dan Naumov) Date: Fri Jun 26 23:37:31 2009 Subject: read/write benchmarking: UFS2 vs ZFS vs EXT3 vs ZFS RAIDZ vs Linux MDRAID Message-ID: To continue the subject of filesystem benchmarking (search the list for READ results posted a few days ago), here are some write and read/write results: Methodology: /data/5M and /data/1M have 5GB of data each in randomly-ordered chunks 5MB and 1MB in size, respectively. /data/zero.bin is a contiguous 8GB file. A process writes a burst of 5MB to a random location in /data/zero.bin once per second; other processes read chunks from /data/1M or /data/5M as appropriate (and as fast as possible) until the entire 5G dataset is read. Contiguous Write Performance: http://virtual.tehinterweb.net/livejournal/2009-06-22_zfs_diskperf/zfs-diskperf-contig-write.png Random Access Read/Write (5mb read chunks): http://virtual.tehinterweb.net/livejournal/2009-06-22_zfs_diskperf/zfs-diskperf-5MB-readwrite.png Random Access Read/Write (1mb read chunks): http://virtual.tehinterweb.net/livejournal/2009-06-22_zfs_diskperf/zfs-diskperf-1MB-readwrite.png These results are from the following forum thread: http://episteme.arstechnica.com/eve/forums/a/tpc/f/96509133/m/857002910041/p/4 Sincerely, - Dan Naumov From ivoras at freebsd.org Sat Jun 27 11:16:06 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Sat Jun 27 11:16:16 2009 Subject: gmirror gm0 destroyed on shutdown; GPT corrupt In-Reply-To: <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> Message-ID: Marcel Moolenaar wrote: > > On Jun 25, 2009, at 4:02 AM, Anton Shterenlikht wrote: >> dev_taste(DEV,mirror/gm0) >> g_part_taste(PART,mirror/gm0) >> >> GEOM: mirror/gm0: the secondary GPT table is corrupt or invalid. >> GEOM: mirror/gm0: using the primary only -- recovery suggested. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > You created the mirror after the GPT, which means you destroyed > the GPT backup header. gmirror uses the last sector on the disk > for metadata and that by itself is a cause for various problems. > > It's better to use gmirror per partition. Or create the GPT partition inside the gmirror device - then the GPT backup table will be at last_sector-1, but... > You could run into a race condition between GPT and gmirror and > GPT winning (again the result of gmirror using the last sector > on a disk for metadata). unfortunately this could still happen, and will lead to the same error if GPT is tasted first, since it is embedded in the first sector and will assume the whole drive is available to GPT, and will then proceed to not find its backup data in the last sector. It looks to me like GEOM classes should have a "priority" field for tasting. Any objections to that idea? From xcllnt at mac.com Sun Jun 28 01:20:52 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Sun Jun 28 01:21:05 2009 Subject: gmirror gm0 destroyed on shutdown; GPT corrupt In-Reply-To: References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> Message-ID: <2FFFB36F-EFA3-4D92-98A3-692BA2D6F63E@mac.com> On Jun 27, 2009, at 4:15 AM, Ivan Voras wrote: > Marcel Moolenaar wrote: >> On Jun 25, 2009, at 4:02 AM, Anton Shterenlikht wrote: >>> dev_taste(DEV,mirror/gm0) >>> g_part_taste(PART,mirror/gm0) >>> >>> GEOM: mirror/gm0: the secondary GPT table is corrupt or invalid. >>> GEOM: mirror/gm0: using the primary only -- recovery suggested. >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> You created the mirror after the GPT, which means you destroyed >> the GPT backup header. gmirror uses the last sector on the disk >> for metadata and that by itself is a cause for various problems. >> It's better to use gmirror per partition. > > Or create the GPT partition inside the gmirror device - then the GPT > backup table will be at last_sector-1, but... > >> You could run into a race condition between GPT and gmirror and >> GPT winning (again the result of gmirror using the last sector >> on a disk for metadata). > > unfortunately this could still happen, and will lead to the same > error if GPT is tasted first, since it is embedded in the first > sector and will assume the whole drive is available to GPT, and will > then proceed to not find its backup data in the last sector. > > It looks to me like GEOM classes should have a "priority" field for > tasting. Any objections to that idea? Using the last sector is not only flawed because it creates a race condition, it's flawed in the assumption that you can always make a geom part of a mirror by storing meta-data on the geom without causing corruption. This whole idea of using the last sector was so that a fully partitioned disk with data could be turned into a mirrored disk. A neat idea, but hardly the basis for a generic mirroring implementation when it silently corrupts a disk. I think it's better to change gmirror to use the first sector on the provider. This never creates a race condition and as such, you don't need to invent a priority scheme, that has it's own set of flaws on top of it. The only downside is that it's not easy to make a fully partitioned and populated disk part of a mirror: one would need to move the data forward one sector to free the first sector. This we can actually do by inserting a GEOM that does it while I/O is still ongoing. The good thing is: we need a class that does exactly this for implementing the "move" verb in gpart. In other words: Solving the problem that putting the metadata in the first sector creates, can and will be re-used in implementing the gpart "move partition" feature. I doubt anyone will complain that the creation of a mirror brings with it a few hours of disk activity that does not inhibit normal operation... -- Marcel Moolenaar xcllnt@mac.com From andrew at modulus.org Sun Jun 28 08:35:21 2009 From: andrew at modulus.org (Andrew Snow) Date: Sun Jun 28 08:35:28 2009 Subject: read/write benchmarking: UFS2 vs ZFS vs EXT3 vs ZFS RAIDZ vs Linux MDRAID In-Reply-To: References: Message-ID: <4A4725FA.80505@modulus.org> > Contiguous Write Performance: > http://virtual.tehinterweb.net/livejournal/2009-06-22_zfs_diskperf/zfs-diskperf-contig-write.png What confuses me about these results is that the '5 disk' performance was barely higher than the 'single disk' performance. All figures are also lower than I get from a single modern SATA disk. My own testing with dd from /dev/zero with FreeBSD ZFS an Intel ICH10 chipset motherboard with Core2duo 2.66ghz showed RAIDZ performance scaling linearly with number of disks: What Write Read -------------------------------- 7 disk RAIDZ2 220 305 6 disk RAIDZ2 173 260 5 disk RAIDZ2 120 213 Only the on-board controllers were used, with Seagate disks of around 250GB capacity. System had 8GB RAM. These results are so different in absolute terms to your results that I don't know how to interpret your set. - Andrew From pjd at FreeBSD.org Sun Jun 28 08:50:01 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Sun Jun 28 08:50:12 2009 Subject: gmirror gm0 destroyed on shutdown; GPT corrupt In-Reply-To: <2FFFB36F-EFA3-4D92-98A3-692BA2D6F63E@mac.com> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <2FFFB36F-EFA3-4D92-98A3-692BA2D6F63E@mac.com> Message-ID: <20090628084957.GB4159@garage.freebsd.pl> On Sat, Jun 27, 2009 at 06:20:49PM -0700, Marcel Moolenaar wrote: > Using the last sector is not only flawed because it creates a race > condition, it's flawed in the assumption that you can always make > a geom part of a mirror by storing meta-data on the geom without > causing corruption. This whole idea of using the last sector was > so that a fully partitioned disk with data could be turned into a > mirrored disk. A neat idea, but hardly the basis for a generic > mirroring implementation when it silently corrupts a disk. This wasn't the idea:) People started putting gmirror on top of partitioned disk, because it was easier/simpler/faster than creating mirror, partitioning and copying the data. I for one never put mirror on already partitioned disk. Although it is sometimes safe to use the last sector. Gjournal already looks for UFS and if UFS is in place, it figures out if the last sector is in use - it isn't if partition size is not multiple of UFS block size. > I think it's better to change gmirror to use the first sector on the > provider. This never creates a race condition and as such, you don't > need to invent a priority scheme, that has it's own set of flaws on > top of it. The only downside is that it's not easy to make a fully > partitioned and populated disk part of a mirror: one would need to > move the data forward one sector to free the first sector. This we > can actually do by inserting a GEOM that does it while I/O is still > ongoing. The good thing is: we need a class that does exactly this > for implementing the "move" verb in gpart. There were two reasons to use the last sector instead of first: 1. You want to be able to boot from gmirror. If all your data will be moved forward your boot sectors and kernel will be harder to find. 2. For recovery reasons you may want to turn off gmirror and still be able to access your data. Note that gmirror can handle the case where disk, slice and partition share the same last sector - it simply stores provider size in its metadata, so once it gets disk for tasting it detects its too big and ignores it, then slice will be given for tasting, but it also has larger size than expected and will be ignored as well. Finally partition will be tasted and gmirror configured. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090628/bc1f0440/attachment.pgp From dan.naumov at gmail.com Sun Jun 28 10:30:28 2009 From: dan.naumov at gmail.com (Dan Naumov) Date: Sun Jun 28 10:30:44 2009 Subject: read/write benchmarking: UFS2 vs ZFS vs EXT3 vs ZFS RAIDZ vs Linux MDRAID In-Reply-To: <4A4725FA.80505@modulus.org> References: <4A4725FA.80505@modulus.org> Message-ID: > What confuses me about these results is that the '5 disk' performance was > barely higher than the 'single disk' performance. ?All figures are also > lower than I get from a single modern SATA disk. > > My own testing with dd from /dev/zero with FreeBSD ZFS an Intel ICH10 > chipset motherboard with Core2duo 2.66ghz showed RAIDZ performance scaling > linearly with number of disks: > > > What ? ? ? ? ? ? ? Write ? Read > -------------------------------- > 7 disk RAIDZ2 ? ? ?220 ? ? 305 > 6 disk RAIDZ2 ? ? ?173 ? ? 260 > 5 disk RAIDZ2 ? ? ?120 ? ? 213 What's confusing is that your results are actually out of place with how ZFS numbers are supposed to look, not mine :) When using ZFS RAIDZ, due to the way parity checking works in ZFS, your pool is SUPPOSED to have throughput of the average single disk from that pool and not some numbers growing skyhigh in a linear fashion. The numbers that did surprise me the most were actually gmirror reads (results posted earlier to this list): a geom gmirror is consistently SLOWER for reading that a single disk (and it only gets progressively worse the more disks you have in your gmirror). Read performance of all other mirroring implementations pretty much scale up linearly with the amount of disks present in the mirror. - Sincerely, Dan Naumov From andrew at modulus.org Sun Jun 28 10:39:58 2009 From: andrew at modulus.org (Andrew Snow) Date: Sun Jun 28 10:40:07 2009 Subject: read/write benchmarking: UFS2 vs ZFS vs EXT3 vs ZFS RAIDZ vs Linux MDRAID In-Reply-To: References: <4A4725FA.80505@modulus.org> Message-ID: <4A4747A0.6040902@modulus.org> > What's confusing is that your results are actually out of place with > how ZFS numbers are supposed to look, not mine :) When using ZFS > RAIDZ, due to the way parity checking works in ZFS, your pool is > SUPPOSED to have throughput of the average single disk from that pool > and not some numbers growing skyhigh in a linear fashion. Could you please elaborate on this and explain it? - Andrew From dan.naumov at gmail.com Sun Jun 28 11:02:04 2009 From: dan.naumov at gmail.com (Dan Naumov) Date: Sun Jun 28 11:02:10 2009 Subject: read/write benchmarking: UFS2 vs ZFS vs EXT3 vs ZFS RAIDZ vs Linux MDRAID In-Reply-To: <4A4747A0.6040902@modulus.org> References: <4A4725FA.80505@modulus.org> <4A4747A0.6040902@modulus.org> Message-ID: "Now we come to the crucial decision ZFS has made for raidz and raidz2: in raidz and raidz2, the data block is striped across all of the disks. Instead of a model where a parity stripe is a bunch of data blocks, each with an independent checksum, ZFS stripes a single data block (and its parity), with a single checksum, across all the disks (or as many of them as necessary). This is a rational implementation decision, but when combined with the need to verify checksums, it has an important consequence: in ZFS, reads always involve all disks, because ZFS always must verify the data block's checksum, which requires reading all of the data block, which is spread across all of the drives. This is unlike normal RAID-5 or RAID-6, in which a small enough read will only touch one drive, and means that adding more disks to a ZFS raidz pool does not increase how many random reads you can do per second. (A normal RAID-5 or RAID-6 array has a (theoretical) random read IO capacity equal to the sum of the random IO operations rate of each of the disks in the array, and so adding another disk adds its IOPs per second to your read capacity. A ZFS raidz or raidz2 pool instead has a capacity equal to the slowest disk's IOPs per second, and adding another disk does nothing to help. Effectively a raidz ZFS gives you a single disk's read IOPs per second rate.)" This was on a blog of a SUN engineer (although a post from a few years ago), unfortunately I don't have the link, I actually had to go through my posting history on the Ars Technica forum to even find this quote in the first place. If the situation has changed and the above quote no longer holds true, it would be nice if someone more knowledgeable on the performance implications could elaborate what kind of performance is to be expected on a raidz system :) - Sincerely, Dan Naumov On Sun, Jun 28, 2009 at 1:36 PM, Andrew Snow wrote: >> What's confusing is that your results are actually out of place with >> how ZFS numbers are supposed to look, not mine :) When using ZFS >> RAIDZ, due to the way parity checking works in ZFS, your pool is >> SUPPOSED to have throughput of the average single disk from that pool >> and not some numbers growing skyhigh in a linear fashion. > > Could you please elaborate on this and explain it? > > - Andrew > From andrew at modulus.org Sun Jun 28 11:37:17 2009 From: andrew at modulus.org (Andrew Snow) Date: Sun Jun 28 11:37:26 2009 Subject: read/write benchmarking: UFS2 vs ZFS vs EXT3 vs ZFS RAIDZ vs Linux MDRAID In-Reply-To: References: <4A4725FA.80505@modulus.org> <4A4747A0.6040902@modulus.org> Message-ID: <4A475511.5000700@modulus.org> OK, I thought we were taling about a single-threaded sequential write which was what my benchmark is. It sounds like the graphs you published were of a multi-threaded writers - how many processes were running in parallel in the case of the "Contiguous Write Performance" here? http://virtual.tehinterweb.net/livejournal/2009-06-22_zfs_diskperf/zfs-diskperf-contig-write.png - Andrew From ivoras at freebsd.org Sun Jun 28 13:18:38 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Sun Jun 28 13:18:56 2009 Subject: gmirror gm0 destroyed on shutdown; GPT corrupt In-Reply-To: <2FFFB36F-EFA3-4D92-98A3-692BA2D6F63E@mac.com> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <2FFFB36F-EFA3-4D92-98A3-692BA2D6F63E@mac.com> Message-ID: <9bbcef730906280551r26e30b61oc84acdd02d94743e@mail.gmail.com> 2009/6/28 Marcel Moolenaar : > Using the last sector is not only flawed because it creates a race > condition, it's flawed in the assumption that you can always make > a geom part of a mirror by storing meta-data on the geom without > causing corruption. This whole idea of using the last sector was > so that a fully partitioned disk with data could be turned into a > mirrored disk. A neat idea, but hardly the basis for a generic > mirroring implementation when it silently corrupts a disk. > > I think it's better to change gmirror to use the first sector on the > provider. Yes, it would be cleaner to implement but it would also make the mirrored devices unbootable. But maybe the class of users needing the functionality is smaller now. > This never creates a race condition and as such, you don't > need to invent a priority scheme, that has it's own set of flaws on > top of it. The only downside is that it's not easy to make a fully > partitioned and populated disk part of a mirror: one would need to > move the data forward one sector to free the first sector. This we > can actually do by inserting a GEOM that does it while I/O is still > ongoing. The good thing is: we need a class that does exactly this > for implementing the "move" verb in gpart. Looks too complicated and fragile. Maybe there's a need for metadata-less automatic mirrors in some way, by storing the configuration somewhere else, possibly in /etc. From spambox at haruhiism.net Sun Jun 28 13:43:52 2009 From: spambox at haruhiism.net (Aisaka Taiga) Date: Sun Jun 28 13:43:58 2009 Subject: gmirror gm0 destroyed on shutdown; GPT corrupt In-Reply-To: <9bbcef730906280551r26e30b61oc84acdd02d94743e@mail.gmail.com> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <2FFFB36F-EFA3-4D92-98A3-692BA2D6F63E@mac.com> <9bbcef730906280551r26e30b61oc84acdd02d94743e@mail.gmail.com> Message-ID: <4A476F56.2030504@haruhiism.net> Ivan Voras wrote: > Yes, it would be cleaner to implement but it would also make the > mirrored devices unbootable. > But maybe the class of users needing the functionality is smaller now. > Most dedicated server providers can't afford to use hardware RAID systems because that would drastically increase the price of a single system; yet many customers want mirroring. > Looks too complicated and fragile. Maybe there's a need for > metadata-less automatic mirrors in some way, by storing the > configuration somewhere else, possibly in /etc. This might be dangerous in some cases. Imagine booting with two drives swapped; such a configuration might lead to data corruption on a volume which was enumerated incorrectly or swapped. -- Kamigishi Rei KREI-RIPE From bugmaster at FreeBSD.org Mon Jun 29 11:06:59 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 29 11:08:08 2009 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200906291106.n5TB6wrZ046329@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/135898 geom [geom] Severe filesystem corruption - large files or l o kern/135874 geom [geom] [patch] geom_linux_lvm misses newer fedora defa o kern/134922 geom [gmirror] [panic] kernel panic when use fdisk on disk o kern/134113 geom [geli] Problem setting secondary GELI key o kern/134044 geom [geom] gmirror(8) overwrites fs with stale data from r o kern/133931 geom [geli] [request] intentionally wrong password to destr o bin/132845 geom [geom] [patch] ggated(8) does not close files opened a o kern/132273 geom glabel(8): [patch] failing on journaled partition o kern/132242 geom [gmirror] gmirror.ko fails to fully initialize o kern/131353 geom [geom] gjournal(8) kernel lock o kern/131037 geom [geli] Unable to create disklabel on .eli-Device p docs/130548 geom [patch] gjournal(8) man page is missing sysctls o kern/130528 geom gjournal fsck during boot o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid o bin/128398 geom [patch] glabel(8): teach geom_label to recognise gpt l f kern/128276 geom [gmirror] machine lock up when gmirror module is used o kern/126902 geom [geom] geom_label: kernel panic during install boot o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s o kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin o kern/124130 geom [gmirror] [usb] gmirror fails to start usb devices tha o kern/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123630 geom [patch] [gmirror] gmirror doesnt allow the original dr o kern/123122 geom [geom] GEOM / gjournal kernel lock o kern/122738 geom [geom] gmirror list "losts consumers" after gmirror de f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/121481 geom [gmirror] data rot on disk with gmirror o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120231 geom [geom] GEOM_CONCAT error adding second drive o kern/120091 geom [geom] [geli] [gjournal] geli does not prompt for pass o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis o kern/120021 geom [geom] [panic] net-p2p/qbittorrent crashes system when o kern/119743 geom [geom] geom label for cds is keeped after dismount and p kern/116896 geom [geom] [patch] Typo in a kassert in GEOM o kern/115856 geom [geli] ZFS thought it was degraded when it should have o kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113885 geom [gmirror] [patch] improved gmirror balance algorithm o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back p bin/110705 geom gmirror(8) control utility does not exit with correct o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o bin/90093 geom fdisk(8) incapable of altering in-core geometry a kern/89660 geom [vinum] [patch] [panic] due to g_malloc returning null o kern/89546 geom [geom] GEOM error s kern/89102 geom [geom] [panic] panic when forced unmount FS from unplu o kern/88601 geom [geli] geli cause kernel panic under heavy disk usage o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu o bin/81779 geom misleading error messages in geom(8) utilities. o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o bin/78131 geom gbde(8) "destroy" not working. s kern/73177 geom kldload geom_* causes panic due to memory exhaustion 63 problems total. From rick-freebsd2008 at kiwi-computer.com Mon Jun 29 21:26:46 2009 From: rick-freebsd2008 at kiwi-computer.com (Rick C. Petty) Date: Mon Jun 29 21:26:52 2009 Subject: gmirror gm0 destroyed on shutdown; GPT corrupt In-Reply-To: <2FFFB36F-EFA3-4D92-98A3-692BA2D6F63E@mac.com> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <2FFFB36F-EFA3-4D92-98A3-692BA2D6F63E@mac.com> Message-ID: <20090629210003.GA24038@keira.kiwi-computer.com> [[ Removing the double cross-post, since this is GEOM-specific ]] On Sat, Jun 27, 2009 at 06:20:49PM -0700, Marcel Moolenaar wrote: > > Using the last sector is not only flawed because it creates a race > condition, It shouldn't create a race condition. If you add a gpt to a mirror, the gpt backup will be the last sector in the mirror, which is the last sector of the disk minus 1. If you want to create the gpt first in anticipation of putting a mirror around it, you would need to do gpt add -s ... where "numsectors" is the output of: diskinfo | awk '{print $4}' In general GEOM requires you to build your topology inward: you're not supposed to create a mirror out of a previously-generated gpt because that's like inserting a new class in between the provider and consumer which doesn't make sense. > it's flawed in the assumption that you can always make > a geom part of a mirror by storing meta-data on the geom without > causing corruption. This whole idea of using the last sector was > so that a fully partitioned disk with data could be turned into a > mirrored disk. A neat idea, but hardly the basis for a generic > mirroring implementation when it silently corrupts a disk. I don't believe this was the assumption, nor the reason for this "feature". > I think it's better to change gmirror to use the first sector on the > provider. Ack! That would be quite disruptive as you would have to increment the sector offset number in the partition table (gpt or mbr) to make the partition bootable. I thought most geom schemes added their metadata at the end, since it fits the "container" philosophy. One exception is gvinum and it's quite painful to make a gvinum root partition bootable. It's even more painful if you ever wish to "undo" it. I've had terrible luck trying to remove gvinum from the picture, whereas gmirror and others are quite easy. > In other words: Solving the problem that putting the metadata in the > first sector creates, can and will be re-used in implementing the > gpart "move partition" feature. I doubt anyone will complain that > the creation of a mirror brings with it a few hours of disk activity > that does not inhibit normal operation... No, but people would roar rather loudly if the partition isn't bootable. To make it bootable, knowledge of each GEOM provider would have to be embedded into boot2, which is already quite full. Sure it's okay for some providers (like raid5 or striping) which you can't boot to already, but such things as simple as mirroring should work to some extent with or without GEOM. -- Rick C. Petty From xcllnt at mac.com Tue Jun 30 21:38:10 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue Jun 30 21:38:17 2009 Subject: gmirror gm0 destroyed on shutdown; GPT corrupt In-Reply-To: <20090629210003.GA24038@keira.kiwi-computer.com> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <2FFFB36F-EFA3-4D92-98A3-692BA2D6F63E@mac.com> <20090629210003.GA24038@keira.kiwi-computer.com> Message-ID: <704EE47D-F0C4-4C63-AA3C-3ADF92CC8379@mac.com> On Jun 29, 2009, at 2:00 PM, Rick C. Petty wrote: > [[ Removing the double cross-post, since this is GEOM-specific ]] > > On Sat, Jun 27, 2009 at 06:20:49PM -0700, Marcel Moolenaar wrote: >> >> Using the last sector is not only flawed because it creates a race >> condition, > > It shouldn't create a race condition. It does. Answer the following: foo0 is a provider with 3 sectors. bar is a geom class that puts meta-data in the first sector. baz is a geom class that puts meta-data in the last sector. Both bar and baz get to taste foo0. Which one should go first? -- Marcel Moolenaar xcllnt@mac.com From rick-freebsd2008 at kiwi-computer.com Tue Jun 30 21:53:47 2009 From: rick-freebsd2008 at kiwi-computer.com (Rick C. Petty) Date: Tue Jun 30 21:53:53 2009 Subject: gmirror gm0 destroyed on shutdown; GPT corrupt In-Reply-To: <704EE47D-F0C4-4C63-AA3C-3ADF92CC8379@mac.com> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <2FFFB36F-EFA3-4D92-98A3-692BA2D6F63E@mac.com> <20090629210003.GA24038@keira.kiwi-computer.com> <704EE47D-F0C4-4C63-AA3C-3ADF92CC8379@mac.com> Message-ID: <20090630215345.GC33849@keira.kiwi-computer.com> On Tue, Jun 30, 2009 at 02:37:55PM -0700, Marcel Moolenaar wrote: > > On Jun 29, 2009, at 2:00 PM, Rick C. Petty wrote: > > >[[ Removing the double cross-post, since this is GEOM-specific ]] > > > >On Sat, Jun 27, 2009 at 06:20:49PM -0700, Marcel Moolenaar wrote: > >> > >>Using the last sector is not only flawed because it creates a race > >>condition, > > > >It shouldn't create a race condition. > > It does. I didn't say it didn't, I said it shouldn't. > Answer the following: > > foo0 is a provider with 3 sectors. > bar is a geom class that puts meta-data in the first sector. > baz is a geom class that puts meta-data in the last sector. > > Both bar and baz get to taste foo0. Which one should go first? Both bar and baz should validate their metadata and it should be pretty apparent that one of them has a smaller size. If the one that is smaller fits perfectly into the one that is bigger, the taste should pass to the latter first. Yes, it would be more complicated to implement, but there *should not* be a race condition because one container fits inside the other. It *should* only be a race condition if one of the classes does not decrease its size to store its metadata. I know of no geom providers which do this. In other words, I meant that it's deterministic. If GEOM can't handle that situation (which *should* be deterministic), then I believe it's broken. -- Rick C. Petty From ivoras at freebsd.org Tue Jun 30 22:08:49 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Jun 30 22:08:54 2009 Subject: gmirror gm0 destroyed on shutdown; GPT corrupt In-Reply-To: <20090630215345.GC33849@keira.kiwi-computer.com> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <2FFFB36F-EFA3-4D92-98A3-692BA2D6F63E@mac.com> <20090629210003.GA24038@keira.kiwi-computer.com> <704EE47D-F0C4-4C63-AA3C-3ADF92CC8379@mac.com> <20090630215345.GC33849@keira.kiwi-computer.com> Message-ID: <9bbcef730906301508l6f2ae344tff8f7495e870049e@mail.gmail.com> 2009/6/30 Rick C. Petty : > On Tue, Jun 30, 2009 at 02:37:55PM -0700, Marcel Moolenaar wrote: > Both bar and baz should validate their metadata and it should be pretty > apparent that one of them has a smaller size. ?If the one that is smaller > fits perfectly into the one that is bigger, the taste should pass to the > latter first. This is how it's currently done with "native" GEOM classes like gmirror - if gmirror is put where it and something else can taste the metadata, gmirror will decide by checking the size - usually +/- 1 sector. But we can't embed this logic into "foreign" classes like GPT. GTP check the first sector (and the last sector for backup), while gmirror checks the first sector, and GPT metadata (AFAIK) doesn't contain media size. From rick-freebsd2008 at kiwi-computer.com Tue Jun 30 22:25:41 2009 From: rick-freebsd2008 at kiwi-computer.com (Rick C. Petty) Date: Tue Jun 30 22:25:48 2009 Subject: gmirror gm0 destroyed on shutdown; GPT corrupt In-Reply-To: <9bbcef730906301508l6f2ae344tff8f7495e870049e@mail.gmail.com> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <2FFFB36F-EFA3-4D92-98A3-692BA2D6F63E@mac.com> <20090629210003.GA24038@keira.kiwi-computer.com> <704EE47D-F0C4-4C63-AA3C-3ADF92CC8379@mac.com> <20090630215345.GC33849@keira.kiwi-computer.com> <9bbcef730906301508l6f2ae344tff8f7495e870049e@mail.gmail.com> Message-ID: <20090630222540.GA34541@keira.kiwi-computer.com> On Wed, Jul 01, 2009 at 12:08:25AM +0200, Ivan Voras wrote: > 2009/6/30 Rick C. Petty : > > On Tue, Jun 30, 2009 at 02:37:55PM -0700, Marcel Moolenaar wrote: > > > Both bar and baz should validate their metadata and it should be pretty > > apparent that one of them has a smaller size. ?If the one that is smaller > > fits perfectly into the one that is bigger, the taste should pass to the > > latter first. > > This is how it's currently done with "native" GEOM classes like > gmirror - if gmirror is put where it and something else can taste the > metadata, gmirror will decide by checking the size - usually +/- 1 > sector. But we can't embed this logic into "foreign" classes like GPT. Then those foreign classes should be given the last opportunity to taste, not the first. > GTP check the first sector (and the last sector for backup), while > gmirror checks the first sector, and GPT metadata (AFAIK) doesn't > contain media size. According to wikipedia, the GPT header contains: - (offset 40) First usable LBA for partitions - (offset 48) Last usable LBA -- Rick C. Petty