From bugmaster at FreeBSD.org Mon Nov 3 03:06:53 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 3 03:07:50 2008 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200811031106.mA3B6qdf010899@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/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 that o kern/123962 geom [panic] gjournal(8): 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 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/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120231 geom [geom] GEOM_CONCAT error adding second drive 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 f 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/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/84556 geom [geom] GBDE-encrypted swap causes panic at shutdown 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 40 problems total. From gavin at FreeBSD.org Mon Nov 3 06:22:40 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Mon Nov 3 06:22:51 2008 Subject: kern/128529: [gjournal] root FS on GEOM Journal cannot boot when journal isn't marked clean/consistent Message-ID: <200811031422.mA3EMejn064535@freefall.freebsd.org> Old Synopsis: root filesystem on GEOM Journal is unable to boot when the journal isn't marked clean/consistent New Synopsis: [gjournal] root FS on GEOM Journal cannot boot when journal isn't marked clean/consistent Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: gavin Responsible-Changed-When: Mon Nov 3 14:18:05 UTC 2008 Responsible-Changed-Why: Over to maintainer(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=128529 From vadim_nuclight at mail.ru Wed Nov 5 03:40:04 2008 From: vadim_nuclight at mail.ru (Vadim Goncharov) Date: Wed Nov 5 03:40:17 2008 Subject: gpart oddity References: <48FF2607.10807@icyb.net.ua> <63F8346D-0116-4F41-BCAA-C235E9657BD8@mac.com> <48FF82BA.3020309@icyb.net.ua> <48FF913A.9070700@icyb.net.ua> <7334715F-FAE1-40EE-92EB-468041587410@mac.com> Message-ID: Hi Marcel Moolenaar! On Wed, 22 Oct 2008 14:03:27 -0700; Marcel Moolenaar wrote about 'Re: gpart oddity': >> Then I remembered that I labeled ad4s1 purely through sysinstall and >> never touched it with disklabel(8), on the other hand I used >> disklabel to label ad4s2. > That's good to know; not that there's a lot we can do about all > those existing installations... >> My personal conclusions: >> 1. sysinstall seems to have handled those fields incorrectly, somehow. >> 2. those fields do not seem to be of any particular use/importance, >> so g_part_bsd might be overly strict here. > Being strict is not a bad thing, but given that we put an > invalid label on all new installations I think it's better > gpart doesn't check it or otherwise detect and corrects it. > (we know the absolute sector offset of the label, so if > secperunit is mediasize + offset, we know the not to flag > the label as invalid, patch it up and move on). The question is, how much strict it is? Currently I have an 6.2-S system with gmirror(8)'ed slices, not disks, as it was converted from existing system with different sizes of disks. I have had edit their labels that partition 'c' doesn't cover entire unit (and last partition was reformatted to be not truncated, too). This is needed to be sure that last sector gets not overwritten by gmirror(8) metadata, but bsdlabel(8) always complains about it that it doesn't cover bla-bla-bla. Moreover, labeled partitions and slices exist on their own, despite of gmirror(8). And yet more, if I try to do a bsdlabel(8) on a gm0, it will complain about 63 sectors boot offset, while on ad0s1 it will not, so I need to hack a lot if I need to resize partitions. What is the cause of the trouble? And, will I have any troubles with that setup when the system will be upgraded to newer major FreeBSD version in a year or two? -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From vadim_nuclight at mail.ru Wed Nov 5 04:17:21 2008 From: vadim_nuclight at mail.ru (Vadim Goncharov) Date: Wed Nov 5 04:17:28 2008 Subject: Experiences with Gpart References: <9e77bdb50810011331y7216eac3yf85907f96f5e8370@mail.gmail.com> <7353F23F-F944-47C9-A97D-6DE247F958AE@mac.com> Message-ID: Hi Marcel Moolenaar! On Sun, 19 Oct 2008 14:40:53 -0700; Marcel Moolenaar wrote about 'Re: Experiences with Gpart': >>>>> Despite the intent of gpt's being to make such nesting >>>>> unnecessary, as >>>>> a means of defining the structure of gmirrors, which take up the >>>>> entire extent of whatever encloses them, the nesting was very >>>>> helpful. >>>> >>>> Maybe nesting simply works if you comment the first if in >>>> g_part_gpt_probe() in >>>> sys/geom/part/g_part_gpt.c ? I don't get why this is restricted, >>>> should be >>>> my >>>> decision to nest or not imo. >>> >>> Nesting is not allowed as per the GPT specification. >> >> OK. It doesn't make much sense for slices too, but is still allowed. > A nested MBR provides for backward compatibility by > presenting a GPT partition as a drive to those legacy > OSes or tools. I don't think it was needed, but it > was envisioned that way, AFAICT. It makes sense in a > weird way. But, allowing for configuring partitioning as user wants (and complex nesting, if one wish) was always strong benefit of the GEOM. So why not? It is allowed author of this thread to manage mirrors the way he wants, not the way somebody enforces. Unix is tools, not policy (c) -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From avg at icyb.net.ua Wed Nov 5 08:17:40 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Nov 5 08:17:58 2008 Subject: zfs: affected by geom_(mbr|bsd) => geom_part_(mbr|bsd) ? Message-ID: <4911C3E9.405@icyb.net.ua> Using GENERIC amd64 7-BETA2 system (installed from "official" ISO) I partitioned my disk for ZFS root file system more or less as described here: https://ish.com.au/solutions/articles/freebsdzfs Big difference is that I created a separate slice to contain a partition for ZFS pool, so that ZFS pool is ad4s2d (and UFS2 boot is ad4s1a). Everything was fine, ZFS root was mounted as expected. Then I built a custom kernel with nooptions for GEOM_(BSD|MBR) and options for GEOM_PART_(BSD|MBR). When I tried to boot this kernel it couldn't mount ZFS root and I simply rebooted my machine when I stuck at mountroot prompt (I couldn't enter UFS2 root because of unrelated keyboard problem). The boot was verbose and I didn't see any peculiar GEOM or GEOM_PART messages (errors, warnings). I'll try to debug this further by booting into UFS root and running gpart, but I'd like to ask for an advice upfront. Can something like this be rationally expected? Is there a way to make ZFS see its pool again (when booted into UFS root)? Thank you! -- Andriy Gapon From marius at nuenneri.ch Wed Nov 5 08:55:12 2008 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Wed Nov 5 08:55:20 2008 Subject: zfs: affected by geom_(mbr|bsd) => geom_part_(mbr|bsd) ? In-Reply-To: <4911C3E9.405@icyb.net.ua> References: <4911C3E9.405@icyb.net.ua> Message-ID: On Wed, Nov 5, 2008 at 5:03 PM, Andriy Gapon wrote: > > Using GENERIC amd64 7-BETA2 system (installed from "official" ISO) I > partitioned my disk for ZFS root file system more or less as described here: > https://ish.com.au/solutions/articles/freebsdzfs > > Big difference is that I created a separate slice to contain a partition > for ZFS pool, so that ZFS pool is ad4s2d (and UFS2 boot is ad4s1a). > > Everything was fine, ZFS root was mounted as expected. > > Then I built a custom kernel with nooptions for GEOM_(BSD|MBR) and > options for GEOM_PART_(BSD|MBR). When I tried to boot this kernel it > couldn't mount ZFS root and I simply rebooted my machine when I stuck at > mountroot prompt (I couldn't enter UFS2 root because of unrelated > keyboard problem). > The boot was verbose and I didn't see any peculiar GEOM or GEOM_PART > messages (errors, warnings). > > I'll try to debug this further by booting into UFS root and running > gpart, but I'd like to ask for an advice upfront. > > Can something like this be rationally expected? > Is there a way to make ZFS see its pool again (when booted into UFS root)? Afaict geom_part is a little bit more concerned about the correctness of the partition tables. I think it's possible that you have a bug in your tables which doesn't matter for geom_mbr or geom_bsd but for geom_part. From xcllnt at mac.com Wed Nov 5 09:28:27 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Nov 5 09:28:34 2008 Subject: gpart oddity In-Reply-To: References: <48FF2607.10807@icyb.net.ua> <63F8346D-0116-4F41-BCAA-C235E9657BD8@mac.com> <48FF82BA.3020309@icyb.net.ua> <48FF913A.9070700@icyb.net.ua> <7334715F-FAE1-40EE-92EB-468041587410@mac.com> Message-ID: <0244407E-F10C-4374-9D68-557C1DA31EB3@mac.com> On Nov 5, 2008, at 3:29 AM, Vadim Goncharov wrote: > Hi Marcel Moolenaar! > > On Wed, 22 Oct 2008 14:03:27 -0700; Marcel Moolenaar wrote about > 'Re: gpart oddity': > >>> Then I remembered that I labeled ad4s1 purely through sysinstall and >>> never touched it with disklabel(8), on the other hand I used >>> disklabel to label ad4s2. >> That's good to know; not that there's a lot we can do about all >> those existing installations... >>> My personal conclusions: >>> 1. sysinstall seems to have handled those fields incorrectly, >>> somehow. >>> 2. those fields do not seem to be of any particular use/importance, >>> so g_part_bsd might be overly strict here. >> Being strict is not a bad thing, but given that we put an >> invalid label on all new installations I think it's better >> gpart doesn't check it or otherwise detect and corrects it. >> (we know the absolute sector offset of the label, so if >> secperunit is mediasize + offset, we know the not to flag >> the label as invalid, patch it up and move on). > > The question is, how much strict it is? Currently I have an 6.2-S > system with > gmirror(8)'ed slices, not disks, as it was converted from existing > system > with different sizes of disks. I have had edit their labels that > partition > 'c' doesn't cover entire unit (and last partition was reformatted to > be not > truncated, too). This is needed to be sure that last sector gets not > overwritten by gmirror(8) metadata, but bsdlabel(8) always complains > about it > that it doesn't cover bla-bla-bla. Moreover, labeled partitions and > slices > exist on their own, despite of gmirror(8). And yet more, if I try to > do a > bsdlabel(8) on a gm0, it will complain about 63 sectors boot offset, > while > on ad0s1 it will not, so I need to hack a lot if I need to resize > partitions. > > What is the cause of the trouble? From what you tell, I think the problem is caused by forcing the proverbial square peg into the proverbial round hole. We made it too easy for people to create invalid labels because we simply didn't do any real sanity checking and/or didn't provide any real tools to help the user achieve what they want. The fact that gmirror puts the metadata in the last sector and only adjusts the media size of the provider when in use, means that we have introduced ambiguity in how the GEOMs are stacked and while the gmirror approach is a feature on the one hand, we have done so without regard for the validity of disklabels. We handwaved the problems as unimportant or aesthetic. -- Marcel Moolenaar xcllnt@mac.com From xcllnt at mac.com Wed Nov 5 09:39:45 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Nov 5 09:39:51 2008 Subject: Experiences with Gpart In-Reply-To: References: <9e77bdb50810011331y7216eac3yf85907f96f5e8370@mail.gmail.com> <7353F23F-F944-47C9-A97D-6DE247F958AE@mac.com> Message-ID: <0A1A5002-A643-4738-B775-5E450C02486A@mac.com> On Nov 5, 2008, at 4:17 AM, Vadim Goncharov wrote: > Hi Marcel Moolenaar! > > On Sun, 19 Oct 2008 14:40:53 -0700; Marcel Moolenaar wrote about > 'Re: Experiences with Gpart': > >>>>>> Despite the intent of gpt's being to make such nesting >>>>>> unnecessary, as >>>>>> a means of defining the structure of gmirrors, which take up the >>>>>> entire extent of whatever encloses them, the nesting was very >>>>>> helpful. >>>>> >>>>> Maybe nesting simply works if you comment the first if in >>>>> g_part_gpt_probe() in >>>>> sys/geom/part/g_part_gpt.c ? I don't get why this is restricted, >>>>> should be >>>>> my >>>>> decision to nest or not imo. >>>> >>>> Nesting is not allowed as per the GPT specification. >>> >>> OK. It doesn't make much sense for slices too, but is still allowed. >> A nested MBR provides for backward compatibility by >> presenting a GPT partition as a drive to those legacy >> OSes or tools. I don't think it was needed, but it >> was envisioned that way, AFAICT. It makes sense in a >> weird way. > > But, allowing for configuring partitioning as user wants (and > complex nesting, > if one wish) was always strong benefit of the GEOM. So why not? It > is allowed > author of this thread to manage mirrors the way he wants, not the > way somebody > enforces. Unix is tools, not policy (c) Gratuitous non-compliance in the name of freedom is not the Unix-way of things. -- Marcel Moolenaar xcllnt@mac.com From jeff+freebsd at wagsky.com Wed Nov 5 11:21:50 2008 From: jeff+freebsd at wagsky.com (Jeff Kletsky) Date: Wed Nov 5 11:21:57 2008 Subject: g_vfs_done() read errors, apparently off end of drive Message-ID: <4911E2DB.3080405@wagsky.com> I'm puzzled by a series of geom read errors as the offset (both before and after changing physical media) appears to be past the end of the drive. The machine in question was brought into service in early September with my notes indicating: # Used 160 GB 2.5? Hitachi on Primary IDE. # Build off FreeBSD 7.0 CD. # Use 40 GB for partition for now. * / ? 512 MB * swap ? 2048 MB * /var ? 10 GB * /tmp ? 10 GB * /usr ? 17914 MB (left) The machine is an old box that has been very reliable (and relatively low power consumption, by today's standards) with a brand new Hitachi drive. It runs my (jailed) webserver and mail relay as well as ISC-dhcpd. The jail-specific file systems are under /var/db and the read-only portions are in /usr/jails/basejail (ezjail default). Starting a few weeks ago, I started getting apparent read errors logged into /var/log/messages at 3 AM: Oct 21 03:02:05 port16 kernel: g_vfs_done():ad0s1f[READ(offset=154543128576, length=16384)]error = 5 Oct 24 03:01:36 port16 kernel: g_vfs_done():ad0s1f[READ(offset=153192726528, length=16384)]error = 5 Oct 25 03:01:38 port16 kernel: g_vfs_done():ad0s1f[READ(offset=153192726528, length=16384)]error = 5 Oct 25 04:15:30 port16 kernel: g_vfs_done():ad0s1f[READ(offset=153192726528, length=16384)]error = 5 Oct 30 03:03:06 port16 kernel: g_vfs_done():ad0s1f[READ(offset=137393258496, length=16384)]error = 5 Nov 1 03:01:16 port16 kernel: g_vfs_done():ad0s1f[READ(offset=142595162112, length=16384)]error = 5 Nov 3 03:02:53 port16 kernel: g_vfs_done():ad0s1f[READ(offset=137199403008, length=16384)]error = 5 Nov 5 03:01:35 port16 kernel: g_vfs_done():ad0s1f[READ(offset=140475858944, length=16384)]error = 5 I took notice of them, and arranged for an RMA for the 160GB drive. Yesterday, November 4th, I formatted an old "10G" drive and used dump/restore to copy over the root, /var, and /usr partitions. The machine came up nicely, but then threw another 3 A.M. read error. I'm especially puzzled as 140475858944, if that is in bytes, would be 140,475,858,944 or ~140GB offset on a drive that has "10G" of addressable storage. Equally puzzling is that my notes indicate that the partition in use before Nov 5th was only 40 G in size, again not a "possible" offset for the error to appear. Here's daily-run output from Oct 25th, confirming that there isn't anything up there at the 140GB mark: Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 496M 129M 327M 28% / devfs 1.0K 1.0K 0B 100% /dev /dev/ad0s1e 9.7G 20K 8.9G 0% /tmp /dev/ad0s1f 17G 3.2G 12G 21% /usr /dev/ad0s1d 9.7G 1.1G 7.8G 12% /var As well as last night's on the smaller drive: Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 434M 129M 270M 32% / devfs 1.0K 1.0K 0B 100% /dev /dev/ad0s1e 484M 14K 445M 0% /tmp /dev/ad0s1f 4.3G 3.2G 790M 81% /usr /dev/ad0s1d 2.9G 1.1G 1.6G 41% /var fsck reports good on all partitions. Any suggestions on how to track this down and resolve it? TIA, Jeff Current dmesg.boot: ------------------- Copyright (c) 1992-2008 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.0-RELEASE-p5 #0: Wed Oct 1 10:10:12 UTC 2008 root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (733.13-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383f9ff real memory = 805224448 (767 MB) avail memory = 774057984 (738 MB) kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Oct 1 2008 10:09:48) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 2ff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 agp0: aperture size is 256M pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib0: no PRT entry for 0.1.INTA vgapci0: port 0xd800-0xd8ff mem 0xf0000000-0xf7ffffff,0xef000000-0xef07ffff irq 10 at device 0.0 on pci1 isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xb800-0xb80f at device 4.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] uhci0: port 0xb400-0xb41f irq 11 at device 4.2 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 0xb000-0xb01f irq 11 at device 4.3 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 pci0: at device 5.0 (no driver attached) em0: port 0xa400-0xa43f mem 0xee800000-0xee81ffff,0xee000000-0xee01ffff irq 11 at device 10.0 on pci0 em0: Ethernet address: 00:1b:21:1d:f4:ed em0: [FILTER] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcbfff pnpid ORM0000 on isa0 fdc0: No FDOUT register! ppc0: at port 0x378-0x37f irq 7 on isa0 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 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 733129479 Hz quality 800 Timecounters tick every 1.000 msec hptrr: no controller detected. ad0: 9773MB at ata0-master UDMA66 Trying to mount root from ufs:/dev/ad0s1a em0: link state changed to UP Hitachi drive line: ------------------- ad0: 152627MB at ata0-master UDMA100 From avg at icyb.net.ua Wed Nov 5 14:00:23 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Nov 5 14:00:30 2008 Subject: zfs: affected by geom_(mbr|bsd) => geom_part_(mbr|bsd) ? In-Reply-To: References: <4911C3E9.405@icyb.net.ua> Message-ID: <49121772.1040501@icyb.net.ua> on 05/11/2008 18:55 Marius N?nnerich said the following: > On Wed, Nov 5, 2008 at 5:03 PM, Andriy Gapon wrote: >> Using GENERIC amd64 7-BETA2 system (installed from "official" ISO) I >> partitioned my disk for ZFS root file system more or less as described here: >> https://ish.com.au/solutions/articles/freebsdzfs >> >> Big difference is that I created a separate slice to contain a partition >> for ZFS pool, so that ZFS pool is ad4s2d (and UFS2 boot is ad4s1a). >> >> Everything was fine, ZFS root was mounted as expected. >> >> Then I built a custom kernel with nooptions for GEOM_(BSD|MBR) and >> options for GEOM_PART_(BSD|MBR). When I tried to boot this kernel it >> couldn't mount ZFS root and I simply rebooted my machine when I stuck at >> mountroot prompt (I couldn't enter UFS2 root because of unrelated >> keyboard problem). >> The boot was verbose and I didn't see any peculiar GEOM or GEOM_PART >> messages (errors, warnings). >> >> I'll try to debug this further by booting into UFS root and running >> gpart, but I'd like to ask for an advice upfront. >> >> Can something like this be rationally expected? >> Is there a way to make ZFS see its pool again (when booted into UFS root)? > > Afaict geom_part is a little bit more concerned about the correctness > of the partition tables. I think it's possible that you have a bug in > your tables which doesn't matter for geom_mbr or geom_bsd but for > geom_part. I believe that disklabels are correct even for gpart, but this is not proven. Anyway I'll do more tests tomorrow. P.S. I kind of hoped for an advice on ZFS side of things. -- Andriy Gapon From cyberleo at cyberleo.net Wed Nov 5 19:58:47 2008 From: cyberleo at cyberleo.net (CyberLeo Kitsana) Date: Wed Nov 5 19:58:53 2008 Subject: Question about labels/names Message-ID: <491267B5.2090206@cyberleo.net> Hi! In the interests of keeping things neat and tidy, I recently, completely at random, randomly included a / character in a geom name (glabel or gmirror) and discovered that it quite happily created a subdirectory under /dev (/dev/mirror or /dev/label, respectively). This seems like a useful method of keeping things tidy, but it smells like a potentially unintended behavior; specifically because removing the label or mirror does not remove the associated directory, and thus recreations fail miserably. No problem for my usage of this feature, but it was a surprise during tinkering and setup. So, the question is this: Is the presence of hierarchial structures in geom provider names an intended feature that can be relied upon, and simply has a bug with regards to removing old provider names; or can I expect my FreeBSD systems to mysteriously fail to mount root with some kernel update in the future? Thank you. -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net Furry Peace! - http://wwww.fur.com/peace/ -------------- next part -------------- [cyberleo@nyoka ~]$ glabel list Geom name: da0 Providers: 1. Name: label/nyoka/ Mediasize: 8589934080 (8.0G) Sectorsize: 512 Mode: r5w5e5 secoffset: 0 offset: 0 seclength: 16777215 length: 8589934080 index: 0 Consumers: 1. Name: da0 Mediasize: 8589934592 (8.0G) Sectorsize: 512 Mode: r5w5e6 Geom name: da1 Providers: 1. Name: label/nyoka/srv Mediasize: 8589934080 (8.0G) Sectorsize: 512 Mode: r1w1e1 secoffset: 0 offset: 0 seclength: 16777215 length: 8589934080 index: 0 Consumers: 1. Name: da1 Mediasize: 8589934592 (8.0G) Sectorsize: 512 Mode: r1w1e2 [cyberleo@nyoka ~]$ ls -laRF /dev/label total 2 dr-xr-xr-x 3 root wheel 512 Dec 31 1969 ./ dr-xr-xr-x 6 root wheel 512 Dec 31 1969 ../ dr-xr-xr-x 2 root wheel 512 Dec 31 1969 nyoka/ /dev/label/nyoka: ls: : No such file or directory total 1 dr-xr-xr-x 2 root wheel 512 Dec 31 1969 ./ dr-xr-xr-x 3 root wheel 512 Dec 31 1969 ../ crw-r----- 1 root operator 0, 88 Oct 12 03:27 a crw-r----- 1 root operator 0, 89 Oct 12 03:27 b crw-r----- 1 root operator 0, 90 Oct 12 03:27 c crw-r----- 1 root operator 0, 91 Oct 12 03:27 d crw-r----- 1 root operator 0, 92 Oct 12 03:27 e crw-r----- 1 root operator 0, 93 Oct 12 03:27 f crw-r----- 1 root operator 0, 83 Oct 12 03:32 srv [cyberleo@nyoka ~]$ bsdlabel /dev/label/nyoka/c # /dev/label/nyoka/c: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 1048576 16 4.2BSD 2048 16384 8 b: 1504912 1048592 swap c: 16777215 0 unused 0 0 # "raw" part, don't edit d: 2848468 2553504 4.2BSD 2048 16384 28552 e: 1048576 5402272 4.2BSD 2048 16384 8 f: 10326367 6450848 4.2BSD 2048 16384 28552 -------------- next part -------------- [cyberleo@paka ~]$ gmirror list Geom name: paka/ State: COMPLETE Components: 2 Balance: split Slice: 4096 Flags: NONE GenID: 0 SyncID: 1 ID: 1693380488 Providers: 1. Name: mirror/paka/ Mediasize: 249999999488 (233G) Sectorsize: 512 Mode: r5w5e5 Consumers: 1. Name: da0 Mediasize: 250000000000 (233G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: DIRTY GenID: 0 SyncID: 1 ID: 2271483065 2. Name: da1 Mediasize: 250000000000 (233G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: DIRTY GenID: 0 SyncID: 1 ID: 1683486829 [cyberleo@paka ~]$ ls -laRF /dev/mirror total 2 dr-xr-xr-x 3 root wheel 512 Oct 25 18:05 ./ dr-xr-xr-x 5 root wheel 512 Oct 25 18:05 ../ dr-xr-xr-x 2 root wheel 512 Oct 25 18:05 paka/ /dev/mirror/paka: ls: : No such file or directory total 1 dr-xr-xr-x 2 root wheel 512 Oct 25 18:05 ./ dr-xr-xr-x 3 root wheel 512 Oct 25 18:05 ../ crw-r----- 1 root operator 0, 101 Oct 25 18:05 a crw-r----- 1 root operator 0, 102 Oct 25 18:05 b crw-r----- 1 root operator 0, 103 Oct 25 18:05 c crw-r----- 1 root operator 0, 104 Oct 25 18:05 d crw-r----- 1 root operator 0, 105 Oct 25 18:05 e crw-r----- 1 root operator 0, 106 Oct 25 18:05 f [cyberleo@paka ~]$ bsdlabel /dev/mirror/paka/c # /dev/mirror/paka/c: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 1572864 16 4.2BSD 2048 16384 28528 b: 2097152 1572880 swap c: 488281249 0 unused 0 0 # "raw" part, don't edit d: 8388608 3670032 4.2BSD 2048 16384 28528 e: 2097152 12058640 4.2BSD 2048 16384 28528 f: 474125457 14155792 4.2BSD 2048 16384 28528 From sgk at troutmask.apl.washington.edu Wed Nov 5 20:25:16 2008 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Wed Nov 5 20:25:22 2008 Subject: Method to mirror a single partition across the net Message-ID: <20081106042504.GA40254@troutmask.apl.washington.edu> I was directed on freebsd-questions to ask my question on freebsd-fs, but freebsd-geom is perhaps a mosre appropriate list. I've read the Handbook's chapter on GEOM, gmirror(1), geom(8), ggated(8), and ggatec(8), and I've search the web for a solution to the following issue. I would like to mirror a single partition on system A to a partition on system B. It would appear a combination of gmirror and ggated would work, but I haven't found any example on setting up two systems. To be specific, /etc/fstab on the 2 systems is # Device Mountpoint FStype Options Dump Pass# /dev/ad4s1b none swap sw 0 0 /dev/ad4s1a / ufs rw 1 1 /dev/ad4s1e /data ufs rw 2 2 /dev/ad4s1d /usr ufs rw 2 2 I want to mirror 192.168.0.20:/dev/ad4s1e to 192.168.0.21:/dev/ad4s1e Does the following method work? On 192.168.0.21: # umount /dev/ad4s1e # echo "192.168.0.21/24 RW /dev/ad4s1e" > /etc/gg.exports # ggated On 192.168.0.20: # ggatec create -o rw 192.168.0.21 /dev/ad4s1e # gmirror label data /dev/ad4s1e # gmirror insert data /dev/ggate0 and /etc/fstab becomes # Device Mountpoint FStype Options Dump Pass# /dev/ad4s1b none swap sw 0 0 /dev/ad4s1a / ufs rw 1 1 /dev/ad4s1d /usr ufs rw 2 2 /dev/mirror/data /data ufs rw 2 2 This also leads to the question that if one is (or both systems are) rebooted, does the mirror automagically come back on boot? -- Steve From brandon at brandonvalentine.com Wed Nov 5 20:35:42 2008 From: brandon at brandonvalentine.com (Brandon Valentine) Date: Wed Nov 5 20:35:50 2008 Subject: Method to mirror a single partition across the net In-Reply-To: <20081106042504.GA40254@troutmask.apl.washington.edu> References: <20081106042504.GA40254@troutmask.apl.washington.edu> Message-ID: <93ed877d0811052035p76c59c96j7d76a178be91a517@mail.gmail.com> On Wed, Nov 5, 2008 at 10:25 PM, Steve Kargl wrote: > I've read the Handbook's chapter on GEOM, gmirror(1), geom(8), ggated(8), > and ggatec(8), and I've search the web for a solution to the following > issue. > > I would like to mirror a single partition on system A to a partition on > system B. It would appear a combination of gmirror and ggated would work, > but I haven't found any example on setting up two systems. Steve, You may find the following two articles helpful: http://phaq.phunsites.net/2006/08/11/realtime-file-system-replication-on-freebsd/ http://blackholemedia.net/blog/2008-01-02-Using_gmirror_ggate_and_freevrrpd_to_create_a_high_availability_enviroment.html Hope this helps, -- Brandon D. Valentine http://www.brandonvalentine.com From sgk at troutmask.apl.washington.edu Wed Nov 5 20:45:50 2008 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Wed Nov 5 20:45:56 2008 Subject: Method to mirror a single partition across the net In-Reply-To: <93ed877d0811052035p76c59c96j7d76a178be91a517@mail.gmail.com> References: <20081106042504.GA40254@troutmask.apl.washington.edu> <93ed877d0811052035p76c59c96j7d76a178be91a517@mail.gmail.com> Message-ID: <20081106044549.GA40427@troutmask.apl.washington.edu> On Wed, Nov 05, 2008 at 10:35:41PM -0600, Brandon Valentine wrote: > On Wed, Nov 5, 2008 at 10:25 PM, Steve Kargl > wrote: > > I've read the Handbook's chapter on GEOM, gmirror(1), geom(8), ggated(8), > > and ggatec(8), and I've search the web for a solution to the following > > issue. > > > > I would like to mirror a single partition on system A to a partition on > > system B. It would appear a combination of gmirror and ggated would work, > > but I haven't found any example on setting up two systems. > > Steve, > > You may find the following two articles helpful: > > http://phaq.phunsites.net/2006/08/11/realtime-file-system-replication-on-freebsd/ > http://blackholemedia.net/blog/2008-01-02-Using_gmirror_ggate_and_freevrrpd_to_create_a_high_availability_enviroment.html > Thanks for the pointers. The first article looks very promising for my needs. -- Steve From phk at phk.freebsd.dk Thu Nov 6 01:31:23 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu Nov 6 01:31:34 2008 Subject: Question about labels/names In-Reply-To: Your message of "Wed, 05 Nov 2008 21:42:45 CST." <491267B5.2090206@cyberleo.net> Message-ID: <15647.1225962849@critter.freebsd.dk> In message <491267B5.2090206@cyberleo.net>, CyberLeo Kitsana writes: >In the interests of keeping things neat and tidy, I recently, completely >at random, randomly included a / character in a geom name (glabel or >gmirror) and discovered that it quite happily created a subdirectory >under /dev (/dev/mirror or /dev/label, respectively). As far as DEVFS it is intended behaviour, for g_label/g_mirror I think it is accidental, but with lulf's recent addition to libgeom, probably beneficial. Any bugs it might cause would be userland utilities not being able to find their geom instances, and lulf's work offers the solution for that. Poul-Henning -- 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 gavin at FreeBSD.org Thu Nov 6 03:44:21 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Thu Nov 6 03:44:27 2008 Subject: kern/119868: [geom_gpt] [patch] 7.0 kernel panic with corrupt GPT label Message-ID: <200811061144.mA6BiLow087904@freefall.freebsd.org> Old Synopsis: [zfs] [patch] 7.0 kernel panic during boot with ZFS and WD1600JS New Synopsis: [geom_gpt] [patch] 7.0 kernel panic with corrupt GPT label Responsible-Changed-From-To: freebsd-fs->freebsd-geom Responsible-Changed-By: gavin Responsible-Changed-When: Thu Nov 6 11:39:24 UTC 2008 Responsible-Changed-Why: Jaakko Heinonen points out that this is actually a bug with geom_gpt and not ZFS. The PR contains a patch, confirmed to fix the issue. http://www.freebsd.org/cgi/query-pr.cgi?pr=119868 From alex.wilkinson at dsto.defence.gov.au Thu Nov 6 04:45:55 2008 From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex) Date: Thu Nov 6 04:46:01 2008 Subject: Question about labels/names In-Reply-To: <15647.1225962849@critter.freebsd.dk> References: <491267B5.2090206@cyberleo.net> <15647.1225962849@critter.freebsd.dk> Message-ID: <20081106123102.GQ50955@stlux503.dsto.defence.gov.au> 0n Thu, Nov 06, 2008 at 09:14:09AM +0000, Poul-Henning Kamp wrote: >Any bugs it might cause would be userland utilities not being able >to find their geom instances, and lulf's work offers the solution >for that. what is "lulf's work" all about ? -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From phk at phk.freebsd.dk Thu Nov 6 04:58:31 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu Nov 6 04:58:38 2008 Subject: Question about labels/names In-Reply-To: Your message of "Thu, 06 Nov 2008 21:31:02 +0900." <20081106123102.GQ50955@stlux503.dsto.defence.gov.au> Message-ID: <16711.1225976307@critter.freebsd.dk> In message <20081106123102.GQ50955@stlux503.dsto.defence.gov.au>, "Wilkinson, A lex" writes: > > 0n Thu, Nov 06, 2008 at 09:14:09AM +0000, Poul-Henning Kamp wrote: > > >Any bugs it might cause would be userland utilities not being able > >to find their geom instances, and lulf's work offers the solution > >for that. > >what is "lulf's work" all about ? Matching /dev entries to geom provider names. See r182843 and r182863. -- 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 kurtseel at primetime.com Thu Nov 6 05:20:33 2008 From: kurtseel at primetime.com (kurt seel) Date: Thu Nov 6 05:20:39 2008 Subject: Method to mirror a single partition across the net In-Reply-To: <20081106042504.GA40254@troutmask.apl.washington.edu> References: <20081106042504.GA40254@troutmask.apl.washington.edu> Message-ID: <4912E80A.7090405@primetime.com> Tell me if this helps : http://bsdtips.utcorp.net/mediawiki/index.php/Mirroring_over_network If anything is wrong or unclear let me know. Steve Kargl wrote: > I was directed on freebsd-questions to ask my question on > freebsd-fs, but freebsd-geom is perhaps a mosre appropriate > list. > > I've read the Handbook's chapter on GEOM, gmirror(1), geom(8), ggated(8), > and ggatec(8), and I've search the web for a solution to the following > issue. > > I would like to mirror a single partition on system A to a partition on > system B. It would appear a combination of gmirror and ggated would work, > but I haven't found any example on setting up two systems. > > To be specific, /etc/fstab on the 2 systems is > > # Device Mountpoint FStype Options Dump Pass# > /dev/ad4s1b none swap sw 0 0 > /dev/ad4s1a / ufs rw 1 1 > /dev/ad4s1e /data ufs rw 2 2 > /dev/ad4s1d /usr ufs rw 2 2 > > I want to mirror 192.168.0.20:/dev/ad4s1e to 192.168.0.21:/dev/ad4s1e > > Does the following method work? > > On 192.168.0.21: > > # umount /dev/ad4s1e > # echo "192.168.0.21/24 RW /dev/ad4s1e" > /etc/gg.exports > # ggated > > On 192.168.0.20: > > # ggatec create -o rw 192.168.0.21 /dev/ad4s1e > # gmirror label data /dev/ad4s1e > # gmirror insert data /dev/ggate0 > > and /etc/fstab becomes > > # Device Mountpoint FStype Options Dump Pass# > /dev/ad4s1b none swap sw 0 0 > /dev/ad4s1a / ufs rw > 1 1 > /dev/ad4s1d /usr ufs rw 2 2 > /dev/mirror/data /data ufs rw 2 2 > > This also leads to the question that if one is (or both systems are) > rebooted, does the mirror automagically come back on boot? > > From marcel at FreeBSD.org Thu Nov 6 08:53:51 2008 From: marcel at FreeBSD.org (marcel@FreeBSD.org) Date: Thu Nov 6 08:53:58 2008 Subject: kern/119868: [geom_gpt] [patch] 7.0 kernel panic with corrupt GPT label Message-ID: <200811061653.mA6GroSY022011@freefall.freebsd.org> Synopsis: [geom_gpt] [patch] 7.0 kernel panic with corrupt GPT label State-Changed-From-To: analyzed->patched State-Changed-By: marcel State-Changed-When: Thu Nov 6 16:52:40 UTC 2008 State-Changed-Why: Fix committed in -CURRENT. MFC to happen in a week. Thanks for the analysis and patch. Responsible-Changed-From-To: freebsd-geom->marcel Responsible-Changed-By: marcel Responsible-Changed-When: Thu Nov 6 16:52:40 UTC 2008 Responsible-Changed-Why: Fix committed in -CURRENT. MFC to happen in a week. Thanks for the analysis and patch. http://www.freebsd.org/cgi/query-pr.cgi?pr=119868 From sgk at troutmask.apl.washington.edu Thu Nov 6 12:38:18 2008 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Thu Nov 6 12:38:25 2008 Subject: Method to mirror a single partition across the net In-Reply-To: <4912E80A.7090405@primetime.com> References: <20081106042504.GA40254@troutmask.apl.washington.edu> <4912E80A.7090405@primetime.com> Message-ID: <20081106203817.GA64185@troutmask.apl.washington.edu> On Thu, Nov 06, 2008 at 07:50:18AM -0500, kurt seel wrote: > > Tell me if this helps : > http://bsdtips.utcorp.net/mediawiki/index.php/Mirroring_over_network > If anything is wrong or unclear let me know. > Thanks for the pointer. Unfortunately, it doesn't describe what I'm trying to do. I literally want to mirror only a single partition across the network to a single partition. I don't want to mirror a disk slice or an entire disk. -- Steve From kurtseel at primetime.com Thu Nov 6 14:20:25 2008 From: kurtseel at primetime.com (kurt seel) Date: Thu Nov 6 14:20:32 2008 Subject: Method to mirror a single partition across the net In-Reply-To: <20081106203817.GA64185@troutmask.apl.washington.edu> References: <20081106042504.GA40254@troutmask.apl.washington.edu> <4912E80A.7090405@primetime.com> <20081106203817.GA64185@troutmask.apl.washington.edu> Message-ID: <49136DE5.1080603@primetime.com> Steve Kargl wrote: > On Thu, Nov 06, 2008 at 07:50:18AM -0500, kurt seel wrote: > >> Tell me if this helps : >> http://bsdtips.utcorp.net/mediawiki/index.php/Mirroring_over_network >> If anything is wrong or unclear let me know. >> >> > > Thanks for the pointer. Unfortunately, it doesn't describe > what I'm trying to do. I literally want to mirror only a > single partition across the network to a single partition. > I don't want to mirror a disk slice or an entire disk. > > Just use the partition device node instead, GEOM doesn't care. From sgk at troutmask.apl.washington.edu Thu Nov 6 15:32:17 2008 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Thu Nov 6 15:32:24 2008 Subject: Method to mirror a single partition across the net In-Reply-To: <49136DE5.1080603@primetime.com> References: <20081106042504.GA40254@troutmask.apl.washington.edu> <4912E80A.7090405@primetime.com> <20081106203817.GA64185@troutmask.apl.washington.edu> <49136DE5.1080603@primetime.com> Message-ID: <20081106233216.GA90456@troutmask.apl.washington.edu> On Thu, Nov 06, 2008 at 05:21:25PM -0500, kurt seel wrote: > Steve Kargl wrote: > >On Thu, Nov 06, 2008 at 07:50:18AM -0500, kurt seel wrote: > > > >>Tell me if this helps : > >>http://bsdtips.utcorp.net/mediawiki/index.php/Mirroring_over_network > >>If anything is wrong or unclear let me know. > >> > >> > > > >Thanks for the pointer. Unfortunately, it doesn't describe > >what I'm trying to do. I literally want to mirror only a > >single partition across the network to a single partition. > >I don't want to mirror a disk slice or an entire disk. > > > Just use the partition device node instead, GEOM doesn't care. Yeah, I hust found this out! node18:root[236] gmirror status Name Status Components mirror/data DEGRADED ad4s1e ggate0 (93%) Thanks, again for the info. -- Steve From sgk at troutmask.apl.washington.edu Thu Nov 6 16:10:54 2008 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Thu Nov 6 16:11:00 2008 Subject: gmirror and nfs Message-ID: <20081107001054.GA90684@troutmask.apl.washington.edu> With Brandon and Kurt's help, I've successfully constructed the gmirror of a partition over the network. Now, onto another (possibly dumb) question. What I have is n18:kargl[213] df -h Filesystem Size Used Avail Capacity Mounted on /dev/ad4s1a 248M 90M 138M 40% / devfs 1.0K 1.0K 0B 100% /dev /dev/ad4s1d 3.9G 419M 3.2G 11% /usr node10:/home 189G 91G 84G 52% /usr/home node10:/usr/local 19G 10G 7.4G 58% /usr/local /dev/mirror/data 218G 20G 180G 10% /data n18:kargl[214] gmirror status Name Status Components mirror/data COMPLETE ad4s1e ggate0 In the above, ad4s1e is n18:/dev/ad4s1 and ggate0 is n19:/dev/ad4s1. On the master node, n10, in my cluster, I tried to do master:root:[213] mount_nfs -o tcp n18:/data /n18 mount_nfs: /n18: Input/output error So, it appears the underlying /dev/mirror/data is not compatible with NFS. Is ggated capable of exporting the gmirror to another node? -- Steve From avasek at yahoo.com Fri Nov 7 01:06:21 2008 From: avasek at yahoo.com (My Myself) Date: Fri Nov 7 04:47:09 2008 Subject: Geom multipath References: <877581.16197.qm@web31702.mail.mud.yahoo.com> <200811061006.13445.lists@jnielsen.net> Message-ID: <225776.3467.qm@web46108.mail.sp1.yahoo.com> Thanks!. I did know that there would be only one active path, but path switching doesnt seem to happen when one path fails. The behaviour is intermittent, so i was wondering if there are any kernel tunables that i could play with, like timeout variables etc. ________________________________ From: John Nielsen To: freebsd-questions@freebsd.org Cc: Ganesh kamath Sent: Thursday, November 6, 2008 8:36:13 PM Subject: Re: Geom multipath On Thursday 06 November 2008 07:13:36 am Ganesh kamath wrote: > I am trying to get multipath running in freebsd version 7. Are there > any configuration files that i can tweak with geom multipath?. The > paths are active/passive to the storage array and i dont seem to have > control of what path the IO takes, so i was wondering if there are any > tweaks thati could do to control the flow of IO to a specific path. Read the manpage. Thoroughly. gmultipath(8). :) There is only one active path to any device, and it is the first in the list of devices. You specify the device list when you create the provider and it is updated if errors occur and when gmultipath labeled devices reappear. I would guess/hope that the order would be preserved across a reboot but I'm not sure. That type of question might be suitable for the freebsd-geom@ mailing list. > Also, the IO doesnt resume when i try to do some cable pulls and plug > them back. If you're not using an mpt or isp disk controller then you have to initiate a rescan manually for the device to reappear. See camcontrol and/or atacontrol. When the device _does_ reappear it will be inserted at the end of the list, so I/O will continue across the alternate path which is still first in the list. JN _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" From sgk at troutmask.apl.washington.edu Fri Nov 7 11:21:51 2008 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Fri Nov 7 11:21:58 2008 Subject: RW and RO semantic and unable to umount a partition? Message-ID: <20081107192150.GA3007@troutmask.apl.washington.edu> So, I may have done something in the category of "Don't do that!". On node n19, I export /dev/ad4s1e and combine it into a mirror on node n18 with n18's /dev/ad4s1e. On n18 I have /dev/mirror/data, and I've successfully mounted /dev/mirror/data: n18:root[32] mount /dev/mirror/data /data Now, I tried the the following: On n18, I created /etc/gg.exports n18:root[33] cat /etc/gg.exports 192.168.0.17 RW /dev/mirror/data n18:root[34] ggated -v On node n17 (yes, a third system). I do n17:root[08] ggatec create -o rw 192.168.0.18 /dev/mirror/data The above command does not create /dev/ggate0. So, I tried ggatec create -o ro 192.168.0.18 /dev/mirror/data This created the /dev/ggate0 device. Now, the interesting part n17:root[10] mount /dev/ggate0 /mnt n17:root[11] ls /mnt .snap/ fcurra/ kargl/ n17:root[12] umount /mnt umount: unmount of /mnt failed: Operation not permitted n17:root[13] umount -f /mnt umount: unmount of /mnt failed: Operation not permitted Three questions. Why is RW not permitted? Why does umount fail? How the heck to I force umount or the unmounting of /mnt? -- Steve From jmrueda at diatel.upm.es Sun Nov 9 01:58:24 2008 From: jmrueda at diatel.upm.es (=?ISO-8859-1?Q?Javier_Mart=EDn_Rueda?=) Date: Sun Nov 9 01:58:31 2008 Subject: RW and RO semantic and unable to umount a partition? In-Reply-To: <20081107192150.GA3007@troutmask.apl.washington.edu> References: <20081107192150.GA3007@troutmask.apl.washington.edu> Message-ID: <4916B19B.7000803@diatel.upm.es> Steve Kargl escribi?: > So, I may have done something in the category of "Don't do that!". > > On node n19, I export /dev/ad4s1e and combine it into a mirror > on node n18 with n18's /dev/ad4s1e. On n18 I have /dev/mirror/data, > and I've successfully mounted /dev/mirror/data: > > n18:root[32] mount /dev/mirror/data /data > > Now, I tried the the following: > > On n18, I created /etc/gg.exports > > n18:root[33] cat /etc/gg.exports > 192.168.0.17 RW /dev/mirror/data > n18:root[34] ggated -v > > On node n17 (yes, a third system). I do > > n17:root[08] ggatec create -o rw 192.168.0.18 /dev/mirror/data > > The above command does not create /dev/ggate0. So, I tried > > ggatec create -o ro 192.168.0.18 /dev/mirror/data > > This created the /dev/ggate0 device. Now, the interesting > part > > n17:root[10] mount /dev/ggate0 /mnt > n17:root[11] ls /mnt > .snap/ fcurra/ kargl/ > n17:root[12] umount /mnt > umount: unmount of /mnt failed: Operation not permitted > n17:root[13] umount -f /mnt > umount: unmount of /mnt failed: Operation not permitted > > Three questions. Why is RW not permitted? Why does umount > fail? How the heck to I force umount or the unmounting of /mnt? > > > RW is not permitted because gmirror has already opened /dev/ad4s1e for RW. The rule is this: you can open a geom provider (disks are also geom providers) RW only once at a time, but you can open a geom provider RO as many times as you want simultaneously or even combine it with one (and only one) RW open. I'm not 100% sure about the umount, but I imagine that, as you mounted it read-write, when you unmount it, it attempts to update the superblock and ggate denies the write because the device is read-only. With regards to forcing the umount, have you tried umount -f /mnt? Finally, even if you manage somehow to open a filesystem RW from two different systems, don't do that. The UFS filesystem is designed so that the disk store is managed by a single kernel, and if you modify it from two or more different kernels at the same time, you will definitely get corruption and panics. From pjd at FreeBSD.org Sun Nov 9 03:50:18 2008 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Sun Nov 9 03:50:45 2008 Subject: RW and RO semantic and unable to umount a partition? In-Reply-To: <20081107192150.GA3007@troutmask.apl.washington.edu> References: <20081107192150.GA3007@troutmask.apl.washington.edu> Message-ID: <20081109111917.GB2340@garage.freebsd.pl> On Fri, Nov 07, 2008 at 11:21:50AM -0800, Steve Kargl wrote: > So, I may have done something in the category of "Don't do that!". > > On node n19, I export /dev/ad4s1e and combine it into a mirror > on node n18 with n18's /dev/ad4s1e. On n18 I have /dev/mirror/data, > and I've successfully mounted /dev/mirror/data: > > n18:root[32] mount /dev/mirror/data /data > > Now, I tried the the following: > > On n18, I created /etc/gg.exports > > n18:root[33] cat /etc/gg.exports > 192.168.0.17 RW /dev/mirror/data > n18:root[34] ggated -v > > On node n17 (yes, a third system). I do > > n17:root[08] ggatec create -o rw 192.168.0.18 /dev/mirror/data > > The above command does not create /dev/ggate0. So, I tried Because /dev/mirror/data is already open for writting by UFS. If you unmount /data on n18, you will be able to attach /dev/mirror/data on n17 for writting. > ggatec create -o ro 192.168.0.18 /dev/mirror/data > > This created the /dev/ggate0 device. Now, the interesting > part > > n17:root[10] mount /dev/ggate0 /mnt > n17:root[11] ls /mnt > .snap/ fcurra/ kargl/ > n17:root[12] umount /mnt > umount: unmount of /mnt failed: Operation not permitted > n17:root[13] umount -f /mnt > umount: unmount of /mnt failed: Operation not permitted > > Three questions. Why is RW not permitted? Why does umount > fail? How the heck to I force umount or the unmounting of /mnt? Not sure why. It might be that file system changed under you (node n18 modified it), so now n17 sees some strange inconsistencies. All in all, you can eigher mount the same file system multiple times read-only OR one time read-write and zero times read-only. -- 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/20081109/0fb32c53/attachment.pgp From kostikbel at gmail.com Sun Nov 9 06:09:54 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Sun Nov 9 06:09:59 2008 Subject: RW and RO semantic and unable to umount a partition? In-Reply-To: <20081109111917.GB2340@garage.freebsd.pl> References: <20081107192150.GA3007@troutmask.apl.washington.edu> <20081109111917.GB2340@garage.freebsd.pl> Message-ID: <20081109133948.GN18100@deviant.kiev.zoral.com.ua> On Sun, Nov 09, 2008 at 12:19:17PM +0100, Pawel Jakub Dawidek wrote: > On Fri, Nov 07, 2008 at 11:21:50AM -0800, Steve Kargl wrote: > > So, I may have done something in the category of "Don't do that!". > > > > On node n19, I export /dev/ad4s1e and combine it into a mirror > > on node n18 with n18's /dev/ad4s1e. On n18 I have /dev/mirror/data, > > and I've successfully mounted /dev/mirror/data: > > > > n18:root[32] mount /dev/mirror/data /data > > > > Now, I tried the the following: > > > > On n18, I created /etc/gg.exports > > > > n18:root[33] cat /etc/gg.exports > > 192.168.0.17 RW /dev/mirror/data > > n18:root[34] ggated -v > > > > On node n17 (yes, a third system). I do > > > > n17:root[08] ggatec create -o rw 192.168.0.18 /dev/mirror/data > > > > The above command does not create /dev/ggate0. So, I tried > > Because /dev/mirror/data is already open for writting by UFS. If you > unmount /data on n18, you will be able to attach /dev/mirror/data on n17 > for writting. > > > ggatec create -o ro 192.168.0.18 /dev/mirror/data > > > > This created the /dev/ggate0 device. Now, the interesting > > part > > > > n17:root[10] mount /dev/ggate0 /mnt > > n17:root[11] ls /mnt > > .snap/ fcurra/ kargl/ > > n17:root[12] umount /mnt > > umount: unmount of /mnt failed: Operation not permitted > > n17:root[13] umount -f /mnt > > umount: unmount of /mnt failed: Operation not permitted > > > > Three questions. Why is RW not permitted? Why does umount > > fail? How the heck to I force umount or the unmounting of /mnt? > > Not sure why. It might be that file system changed under you (node n18 > modified it), so now n17 sees some strange inconsistencies. > > All in all, you can eigher mount the same file system multiple times > read-only OR one time read-write and zero times read-only. Better not mount ufs volume more then once regardless of the mount mode. See the start of the ffs_mountfs(). ffs mount modifies devvp bufobj with reference to geom consumer. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20081109/0dd9247e/attachment.pgp From pjd at FreeBSD.org Sun Nov 9 09:09:10 2008 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Sun Nov 9 09:09:17 2008 Subject: RW and RO semantic and unable to umount a partition? In-Reply-To: <20081109133948.GN18100@deviant.kiev.zoral.com.ua> References: <20081107192150.GA3007@troutmask.apl.washington.edu> <20081109111917.GB2340@garage.freebsd.pl> <20081109133948.GN18100@deviant.kiev.zoral.com.ua> Message-ID: <20081109170900.GC2340@garage.freebsd.pl> On Sun, Nov 09, 2008 at 03:39:48PM +0200, Kostik Belousov wrote: > On Sun, Nov 09, 2008 at 12:19:17PM +0100, Pawel Jakub Dawidek wrote: > > Not sure why. It might be that file system changed under you (node n18 > > modified it), so now n17 sees some strange inconsistencies. > > > > All in all, you can eigher mount the same file system multiple times > > read-only OR one time read-write and zero times read-only. > > Better not mount ufs volume more then once regardless of the mount mode. > See the start of the ffs_mountfs(). ffs mount modifies devvp bufobj with > reference to geom consumer. Yes, I know, I even had patch for that, although here I was talking about mounting the same FS read-only on few separate machines using ggate. -- 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/20081109/1abf6ce9/attachment.pgp From sgk at troutmask.apl.washington.edu Sun Nov 9 09:38:56 2008 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Sun Nov 9 09:39:10 2008 Subject: RW and RO semantic and unable to umount a partition? In-Reply-To: <20081109111917.GB2340@garage.freebsd.pl> References: <20081107192150.GA3007@troutmask.apl.washington.edu> <20081109111917.GB2340@garage.freebsd.pl> Message-ID: <20081109173856.GA18430@troutmask.apl.washington.edu> On Sun, Nov 09, 2008 at 12:19:17PM +0100, Pawel Jakub Dawidek wrote: > On Fri, Nov 07, 2008 at 11:21:50AM -0800, Steve Kargl wrote: > > So, I may have done something in the category of "Don't do that!". > > > > On node n19, I export /dev/ad4s1e and combine it into a mirror > > on node n18 with n18's /dev/ad4s1e. On n18 I have /dev/mirror/data, > > and I've successfully mounted /dev/mirror/data: > > > > n18:root[32] mount /dev/mirror/data /data > > > > Now, I tried the the following: > > > > On n18, I created /etc/gg.exports > > > > n18:root[33] cat /etc/gg.exports > > 192.168.0.17 RW /dev/mirror/data > > n18:root[34] ggated -v > > > > On node n17 (yes, a third system). I do > > > > n17:root[08] ggatec create -o rw 192.168.0.18 /dev/mirror/data > > > > The above command does not create /dev/ggate0. So, I tried > > Because /dev/mirror/data is already open for writting by UFS. If you > unmount /data on n18, you will be able to attach /dev/mirror/data on n17 > for writting. > Thanks for the reply. Unfortunately, my experiment with geom leads me to believe that it lacks the features that I need. My attempts at using geom with n17 has necessitated a re-install of the OS because n17 can no longer use NFS to mount filesystems without a Read/Write error. -- Steve From bugmaster at FreeBSD.org Mon Nov 10 03:06:51 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 10 03:07:59 2008 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200811101106.mAAB6oAm049714@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/128529 geom [gjournal] root FS on GEOM Journal cannot boot when jo o kern/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 that 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 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/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120231 geom [geom] GEOM_CONCAT error adding second drive 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 f 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/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/84556 geom [geom] GBDE-encrypted swap causes panic at shutdown 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 41 problems total. From vadim_nuclight at mail.ru Mon Nov 10 03:41:27 2008 From: vadim_nuclight at mail.ru (Vadim Goncharov) Date: Mon Nov 10 03:41:34 2008 Subject: gpart oddity References: <48FF2607.10807@icyb.net.ua> <63F8346D-0116-4F41-BCAA-C235E9657BD8@mac.com> <48FF82BA.3020309@icyb.net.ua> <48FF913A.9070700@icyb.net.ua> <7334715F-FAE1-40EE-92EB-468041587410@mac.com> <0244407E-F10C-4374-9D68-557C1DA31EB3@mac.com> Message-ID: Hi Marcel Moolenaar! On Wed, 05 Nov 2008 09:28:19 -0800; Marcel Moolenaar wrote about 'Re: gpart oddity': >> The question is, how much strict it is? Currently I have an 6.2-S >> system with >> gmirror(8)'ed slices, not disks, as it was converted from existing >> system >> with different sizes of disks. I have had edit their labels that >> partition >> 'c' doesn't cover entire unit (and last partition was reformatted to >> be not >> truncated, too). This is needed to be sure that last sector gets not >> overwritten by gmirror(8) metadata, but bsdlabel(8) always complains >> about it >> that it doesn't cover bla-bla-bla. Moreover, labeled partitions and >> slices >> exist on their own, despite of gmirror(8). And yet more, if I try to >> do a >> bsdlabel(8) on a gm0, it will complain about 63 sectors boot offset, >> while >> on ad0s1 it will not, so I need to hack a lot if I need to resize >> partitions. >> >> What is the cause of the trouble? > From what you tell, I think the problem is caused by > forcing the proverbial square peg into the proverbial > round hole. > We made it too easy for people to create invalid labels > because we simply didn't do any real sanity checking > and/or didn't provide any real tools to help the user > achieve what they want. > The fact that gmirror puts the metadata in the last > sector and only adjusts the media size of the provider > when in use, means that we have introduced ambiguity > in how the GEOMs are stacked and while the gmirror > approach is a feature on the one hand, we have done so > without regard for the validity of disklabels. We > handwaved the problems as unimportant or aesthetic. But the question is, what I will have to do with my setup? Will it still work in future versions? -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From vadim_nuclight at mail.ru Mon Nov 10 03:50:04 2008 From: vadim_nuclight at mail.ru (Vadim Goncharov) Date: Mon Nov 10 03:50:11 2008 Subject: Experiences with Gpart References: <9e77bdb50810011331y7216eac3yf85907f96f5e8370@mail.gmail.com> <7353F23F-F944-47C9-A97D-6DE247F958AE@mac.com> <0A1A5002-A643-4738-B775-5E450C02486A@mac.com> Message-ID: Hi Marcel Moolenaar! On Wed, 05 Nov 2008 09:39:43 -0800; Marcel Moolenaar wrote about 'Re: Experiences with Gpart': >>>>>>> Despite the intent of gpt's being to make such nesting >>>>>>> unnecessary, as >>>>>>> a means of defining the structure of gmirrors, which take up the >>>>>>> entire extent of whatever encloses them, the nesting was very >>>>>>> helpful. >>>>>> >>>>>> Maybe nesting simply works if you comment the first if in >>>>>> g_part_gpt_probe() in >>>>>> sys/geom/part/g_part_gpt.c ? I don't get why this is restricted, >>>>>> should be >>>>>> my >>>>>> decision to nest or not imo. >>>>> >>>>> Nesting is not allowed as per the GPT specification. >>>> >>>> OK. It doesn't make much sense for slices too, but is still allowed. >>> A nested MBR provides for backward compatibility by >>> presenting a GPT partition as a drive to those legacy >>> OSes or tools. I don't think it was needed, but it >>> was envisioned that way, AFAICT. It makes sense in a >>> weird way. >> >> But, allowing for configuring partitioning as user wants (and >> complex nesting, >> if one wish) was always strong benefit of the GEOM. So why not? It >> is allowed >> author of this thread to manage mirrors the way he wants, not the >> way somebody >> enforces. Unix is tools, not policy (c) > > Gratuitous non-compliance in the name of freedom is > not the Unix-way of things. Unix always had at least knob allow_me_to_shoot_in_the_foot, if now allowed this directly. So what alternative do you propose to group partitions together or to split GPT partitions? bsdlabel? But that is limited to 26 partitions and 2^32 sectors. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From avg at icyb.net.ua Tue Nov 11 05:24:50 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue Nov 11 05:24:55 2008 Subject: "unused" partition: disklabel vs. gpart Message-ID: <4919879E.5080900@icyb.net.ua> It seems that there is a difference in how disklabel-based code and part code handle partitions with type "unused". As I understand disklabel sees a difference between partitions that do not exist (i.e. lines are not there in disklabel output) and partitions marked unused. geom_bsd code doesn't create devices for the former and does create for the latter. On the other hand geom_part_bsd code seems to treat "unused" as non-existent and doesn't create device for them and doesn't display them in gpart show output. E.g. I had a label with a single partition 'd' with type unused. I actually put ZFS pool into this partition, but marked it 'unused', so that some smart scripts on certain live cds do not try to mount or swappon the partitions. This worked OK with geom_bsd, but geom_part_bsd considered the slice entirely empty, it didn't find the 'd' partition in it. -- Andriy Gapon From avg at icyb.net.ua Tue Nov 11 05:35:26 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue Nov 11 05:35:38 2008 Subject: zfs: affected by geom_(mbr|bsd) => geom_part_(mbr|bsd) ? In-Reply-To: <4911C3E9.405@icyb.net.ua> References: <4911C3E9.405@icyb.net.ua> Message-ID: <49198A1A.3080600@icyb.net.ua> on 05/11/2008 18:03 Andriy Gapon said the following: > Using GENERIC amd64 7-BETA2 system (installed from "official" ISO) I > partitioned my disk for ZFS root file system more or less as described here: > https://ish.com.au/solutions/articles/freebsdzfs > > Big difference is that I created a separate slice to contain a partition > for ZFS pool, so that ZFS pool is ad4s2d (and UFS2 boot is ad4s1a). > > Everything was fine, ZFS root was mounted as expected. > > Then I built a custom kernel with nooptions for GEOM_(BSD|MBR) and > options for GEOM_PART_(BSD|MBR). When I tried to boot this kernel it > couldn't mount ZFS root and I simply rebooted my machine when I stuck at > mountroot prompt (I couldn't enter UFS2 root because of unrelated > keyboard problem). > The boot was verbose and I didn't see any peculiar GEOM or GEOM_PART > messages (errors, warnings). > > I'll try to debug this further by booting into UFS root and running > gpart, but I'd like to ask for an advice upfront. So I did this. Here are some data: $ gpart show => 63 976773105 ad6 MBR (500.1GB) 63 12578832 1 freebsd [active] (6.4GB) 12578895 964189170 2 freebsd (493.7GB) 976768065 5103 - free - (2.6MB) => 0 12578832 ad6s1 BSD (6.4GB) 0 16 - free - (8.2KB) 16 2097152 1 freebsd-ufs (1073.7MB) 2097168 2097152 - free - (1073.7MB) 4194320 8384512 2 freebsd-swap (4.3GB) => 0 964189170 ad6s2 BSD (493.7GB) 0 16 - free - (8.2KB) 16 964189154 4 freebsd-swap (493.7GB) $ zpool status pool: tank state: UNAVAIL status: One or more devices could not be opened. There are insufficient replicas for the pool to continue functioning. action: Attach the missing device and online it using 'zpool online'. see: http://www.sun.com/msg/ZFS-8000-D3 scrub: none requested config: NAME STATE READ WRITE CKSUM tank UNAVAIL 0 0 0 insufficient replicas ad6s2d UNAVAIL 0 0 0 cannot open So gpart sees ad6s2d perfectly well, it has the same parameters as disklabel previously reported and /dev/ad6s2d exists. But zfs "cannot open" it. What I did next was: 1. reboot into "disklabel" kernel single-user 2. zpool export tank 3. reboot into gpart kernel single-user 4. zpool import - it saw tank correctly 5. zpool import tank 6. profit! :-) As I see it, zpool.cache contained something about ad6s2d that prevented gpart ad6s2d from being recognized as the same device as "disklabel" one. I really wonder what that could have been? Or maybe gpart reported some subtle property of the device differently... -- Andriy Gapon From bugmaster at FreeBSD.org Mon Nov 17 03:06:50 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 17 03:08:02 2008 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200811171106.mAHB6nVi082520@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/128529 geom [gjournal] root FS on GEOM Journal cannot boot when jo o kern/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 that 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 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/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120231 geom [geom] GEOM_CONCAT error adding second drive 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 f 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/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/84556 geom [geom] GBDE-encrypted swap causes panic at shutdown 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 41 problems total. From xcllnt at mac.com Mon Nov 17 20:21:31 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Mon Nov 17 20:21:38 2008 Subject: Experiences with Gpart In-Reply-To: References: <9e77bdb50810011331y7216eac3yf85907f96f5e8370@mail.gmail.com> <7353F23F-F944-47C9-A97D-6DE247F958AE@mac.com> <0A1A5002-A643-4738-B775-5E450C02486A@mac.com> Message-ID: [sorry for the delay] On Nov 10, 2008, at 3:45 AM, Vadim Goncharov wrote: >>> But, allowing for configuring partitioning as user wants (and >>> complex nesting, >>> if one wish) was always strong benefit of the GEOM. So why not? It >>> is allowed >>> author of this thread to manage mirrors the way he wants, not the >>> way somebody >>> enforces. Unix is tools, not policy (c) >> >> Gratuitous non-compliance in the name of freedom is >> not the Unix-way of things. > > Unix always had at least knob allow_me_to_shoot_in_the_foot, if now > allowed > this directly. So what alternative do you propose to group > partitions together > or to split GPT partitions? bsdlabel? But that is limited to 26 > partitions > and 2^32 sectors. FreeBSD allowed nested GPTs before and I didn't change this in GPart. Put differently: I didn't add special code to disallow it. By way of how GEOM works, FreeBSD will support it by default: # mdconfig -a -t malloc -s 128m md0 # gpart create -s gpt md0 md0 created # gpart add -b 34 -s 131038 -t freebsd md0 md0s1 added # gpart add -b 131072 -s 131038 -t freebsd md0 md0s2 added # gpart create -s gpt md0s1 md0s1 created # gpart create -s gpt md0s2 md0s2 created # gpart show | grep GPT => 34 262077 md0 GPT (128M) => 34 130971 md0s1 GPT (64M) => 34 130971 md0s2 GPT (64M) FYI, -- Marcel Moolenaar xcllnt@mac.com From xcllnt at mac.com Mon Nov 17 20:42:53 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Mon Nov 17 20:42:59 2008 Subject: "unused" partition: disklabel vs. gpart In-Reply-To: <4919879E.5080900@icyb.net.ua> References: <4919879E.5080900@icyb.net.ua> Message-ID: [sorry for the delay] On Nov 11, 2008, at 5:24 AM, Andriy Gapon wrote: > E.g. I had a label with a single partition 'd' with type unused. I > actually put ZFS pool into this partition, but marked it 'unused', so > that some smart scripts on certain live cds do not try to mount or > swappon the partitions. This worked OK with geom_bsd, but > geom_part_bsd > considered the slice entirely empty, it didn't find the 'd' > partition in it. Hmmm... Let me think about this one. While I don't like the ambiguity, if historically you could have partitions of type FS_UNUSED (other than 'c') then GPart should allow that too... -- Marcel Moolenaar xcllnt@mac.com From xcllnt at mac.com Mon Nov 17 21:27:20 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Mon Nov 17 21:27:26 2008 Subject: zfs: affected by geom_(mbr|bsd) => geom_part_(mbr|bsd) ? In-Reply-To: <49198A1A.3080600@icyb.net.ua> References: <4911C3E9.405@icyb.net.ua> <49198A1A.3080600@icyb.net.ua> Message-ID: [sorry for the delay] On Nov 11, 2008, at 5:35 AM, Andriy Gapon wrote: > on 05/11/2008 18:03 Andriy Gapon said the following: >> Using GENERIC amd64 7-BETA2 system (installed from "official" ISO) I *snip* >> Then I built a custom kernel with nooptions for GEOM_(BSD|MBR) and >> options for GEOM_PART_(BSD|MBR). When I tried to boot this kernel it >> couldn't mount ZFS root and I simply rebooted my machine when I >> stuck at >> mountroot prompt (I couldn't enter UFS2 root because of unrelated >> keyboard problem). >> The boot was verbose and I didn't see any peculiar GEOM or GEOM_PART >> messages (errors, warnings). The problem is very likely related to change 184204. This change fixes a conflict between MBR and BSD. Unfortunately this fix wasn't in 7.1-BETA2. You should not have a problem with 7.1-RELEASE (nor 7-STABLE). FYI, -- Marcel Moolenaar xcllnt@mac.com From xcllnt at mac.com Mon Nov 17 21:56:39 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Mon Nov 17 21:56:45 2008 Subject: "unused" partition: disklabel vs. gpart In-Reply-To: References: <4919879E.5080900@icyb.net.ua> Message-ID: On Nov 17, 2008, at 8:42 PM, Marcel Moolenaar wrote: > [sorry for the delay] > > On Nov 11, 2008, at 5:24 AM, Andriy Gapon wrote: > >> E.g. I had a label with a single partition 'd' with type unused. I >> actually put ZFS pool into this partition, but marked it 'unused', so >> that some smart scripts on certain live cds do not try to mount or >> swappon the partitions. This worked OK with geom_bsd, but >> geom_part_bsd >> considered the slice entirely empty, it didn't find the 'd' >> partition in it. > > Hmmm... Let me think about this one. While I don't > like the ambiguity, if historically you could have > partitions of type FS_UNUSED (other than 'c') then > GPart should allow that too... I fixed GPart. Thanks for pointing it out. -- Marcel Moolenaar xcllnt@mac.com From avg at icyb.net.ua Tue Nov 18 00:05:57 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue Nov 18 00:06:04 2008 Subject: "unused" partition: disklabel vs. gpart In-Reply-To: References: <4919879E.5080900@icyb.net.ua> Message-ID: <4922775D.6050701@icyb.net.ua> on 18/11/2008 07:56 Marcel Moolenaar said the following: > > On Nov 17, 2008, at 8:42 PM, Marcel Moolenaar wrote: > >> [sorry for the delay] >> >> On Nov 11, 2008, at 5:24 AM, Andriy Gapon wrote: >> >>> E.g. I had a label with a single partition 'd' with type unused. I >>> actually put ZFS pool into this partition, but marked it 'unused', so >>> that some smart scripts on certain live cds do not try to mount or >>> swappon the partitions. This worked OK with geom_bsd, but geom_part_bsd >>> considered the slice entirely empty, it didn't find the 'd' partition >>> in it. >> >> Hmmm... Let me think about this one. While I don't >> like the ambiguity, if historically you could have >> partitions of type FS_UNUSED (other than 'c') then >> GPart should allow that too... > > I fixed GPart. > Thanks for pointing it out. > Thank you! -- Andriy Gapon From avg at icyb.net.ua Tue Nov 18 00:10:30 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue Nov 18 00:10:42 2008 Subject: zfs: affected by geom_(mbr|bsd) => geom_part_(mbr|bsd) ? In-Reply-To: References: <4911C3E9.405@icyb.net.ua> <49198A1A.3080600@icyb.net.ua> Message-ID: <49227875.6090902@icyb.net.ua> on 18/11/2008 07:27 Marcel Moolenaar said the following: > [sorry for the delay] > > On Nov 11, 2008, at 5:35 AM, Andriy Gapon wrote: > >> on 05/11/2008 18:03 Andriy Gapon said the following: >>> Using GENERIC amd64 7-BETA2 system (installed from "official" ISO) I > *snip* >>> Then I built a custom kernel with nooptions for GEOM_(BSD|MBR) and >>> options for GEOM_PART_(BSD|MBR). When I tried to boot this kernel it >>> couldn't mount ZFS root and I simply rebooted my machine when I stuck at >>> mountroot prompt (I couldn't enter UFS2 root because of unrelated >>> keyboard problem). >>> The boot was verbose and I didn't see any peculiar GEOM or GEOM_PART >>> messages (errors, warnings). > > The problem is very likely related to change 184204. This > change fixes a conflict between MBR and BSD. Unfortunately > this fix wasn't in 7.1-BETA2. You should not have a problem > with 7.1-RELEASE (nor 7-STABLE). Marcel, this particular change was definitely in kernel. As I reported in subsequent posts gpart show reported everything correctly and device node existed in dev, etc. UFS was happy about all its partitions, only ZFS had trouble. I think that this was something different, more subtle. -- Andriy Gapon From xcllnt at mac.com Tue Nov 18 08:45:39 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue Nov 18 08:45:46 2008 Subject: zfs: affected by geom_(mbr|bsd) => geom_part_(mbr|bsd) ? In-Reply-To: <49227875.6090902@icyb.net.ua> References: <4911C3E9.405@icyb.net.ua> <49198A1A.3080600@icyb.net.ua> <49227875.6090902@icyb.net.ua> Message-ID: <93FC5F5D-91CD-450B-B08D-5C5EC5A1C880@mac.com> On Nov 18, 2008, at 12:10 AM, Andriy Gapon wrote: > on 18/11/2008 07:27 Marcel Moolenaar said the following: >> [sorry for the delay] >> On Nov 11, 2008, at 5:35 AM, Andriy Gapon wrote: >>> on 05/11/2008 18:03 Andriy Gapon said the following: >>>> Using GENERIC amd64 7-BETA2 system (installed from "official" >>>> ISO) I >> *snip* >>>> Then I built a custom kernel with nooptions for GEOM_(BSD|MBR) and >>>> options for GEOM_PART_(BSD|MBR). When I tried to boot this kernel >>>> it >>>> couldn't mount ZFS root and I simply rebooted my machine when I >>>> stuck at >>>> mountroot prompt (I couldn't enter UFS2 root because of unrelated >>>> keyboard problem). >>>> The boot was verbose and I didn't see any peculiar GEOM or >>>> GEOM_PART >>>> messages (errors, warnings). >> The problem is very likely related to change 184204. This >> change fixes a conflict between MBR and BSD. Unfortunately >> this fix wasn't in 7.1-BETA2. You should not have a problem >> with 7.1-RELEASE (nor 7-STABLE). > > Marcel, > > this particular change was definitely in kernel. > As I reported in subsequent posts gpart show reported everything > correctly and device node existed in dev, etc. UFS was happy about > all its partitions, only ZFS had trouble. I think that this was > something different, more subtle. Hmmm... this goes over my head. Some ZFS guru needs to tell us what criteria are being checked exactly before a disk/provider is considered the one recorded in the meta-data. -- Marcel Moolenaar xcllnt@mac.com From avg at icyb.net.ua Tue Nov 18 09:29:46 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue Nov 18 09:29:57 2008 Subject: zfs: affected by geom_(mbr|bsd) => geom_part_(mbr|bsd) ? In-Reply-To: <93FC5F5D-91CD-450B-B08D-5C5EC5A1C880@mac.com> References: <4911C3E9.405@icyb.net.ua> <49198A1A.3080600@icyb.net.ua> <49227875.6090902@icyb.net.ua> <93FC5F5D-91CD-450B-B08D-5C5EC5A1C880@mac.com> Message-ID: <4922FB81.50608@icyb.net.ua> I just remembered that I saved old zpool.cache file before "migrating" the pool. I looked at the diff of hexdumps and there are a number of differences, it's hard to understand them because the file is binary (actually it seems to contain serialized name-value pairs), but one difference is prominent: ... 00000260 64 65 76 69 64 00 00 00 00 00 00 09 00 00 00 01 |devid...........| ... -00000270 00 00 00 15 61 64 3a 47 45 41 35 33 34 52 46 30 |....ad:GEA534RF0| -00000280 54 4b 33 35 41 73 31 73 33 00 00 00 00 00 00 28 |TK35As1s3......(| ... +00000270 00 00 00 11 61 64 3a 47 45 41 35 33 34 52 46 30 |....ad:GEA534RF0| +00000280 54 4b 33 35 41 00 00 00 00 00 00 28 00 00 00 28 |TK35A......(...(| ... It looks like old "devid" value is "ad:GEA534RF0TK35As1s3" and new one is "ad:GEA534RF0TK35A". Just a reminder: actual zpool device is ad6s2d. The new value is what is reported by diskinfo: $ diskinfo -v ad6 ad6 ... ad:GEA534RF0TK35A # Disk ident. $ diskinfo -v ad6s2 ad6s2 ... ad:GEA534RF0TK35A # Disk ident. $ diskinfo -v ad6s2d ad6s2d ... ad:GEA534RF0TK35A # Disk ident. Hmm, "indent" is reported to be the same for all three entities. I don't remember what diskinfo reported with pre-gpart kernel, but I suspect that it was something different. Could anybody please check this? (on 7.X machine without GEOM_PART). I quickly glimpsed through sources and it seems that this comes from DIOCGIDENT GEOM ioctl i.e. "GEOM::ident" attribute. It seems that geom_slice.c code has some special handling for that. -- Andriy Gapon From xcllnt at mac.com Tue Nov 18 11:50:01 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue Nov 18 11:50:13 2008 Subject: zfs: affected by geom_(mbr|bsd) => geom_part_(mbr|bsd) ? In-Reply-To: <4922FB81.50608@icyb.net.ua> References: <4911C3E9.405@icyb.net.ua> <49198A1A.3080600@icyb.net.ua> <49227875.6090902@icyb.net.ua> <93FC5F5D-91CD-450B-B08D-5C5EC5A1C880@mac.com> <4922FB81.50608@icyb.net.ua> Message-ID: <022C4222-63B2-4535-8B7E-0426E9CE2BEA@mac.com> On Nov 18, 2008, at 9:29 AM, Andriy Gapon wrote: > I just remembered that I saved old zpool.cache file before "migrating" > the pool. > I looked at the diff of hexdumps and there are a number of > differences, > it's hard to understand them because the file is binary (actually it > seems to contain serialized name-value pairs), but one difference is > prominent: > ... > 00000260 64 65 76 69 64 00 00 00 00 00 00 09 00 00 00 01 > |devid...........| > ... > -00000270 00 00 00 15 61 64 3a 47 45 41 35 33 34 52 46 30 > |....ad:GEA534RF0| > -00000280 54 4b 33 35 41 73 31 73 33 00 00 00 00 00 00 28 > |TK35As1s3......(| > ... > +00000270 00 00 00 11 61 64 3a 47 45 41 35 33 34 52 46 30 > |....ad:GEA534RF0| > +00000280 54 4b 33 35 41 00 00 00 00 00 00 28 00 00 00 28 > |TK35A......(...(| > ... > > It looks like old "devid" value is "ad:GEA534RF0TK35As1s3" and new one > is "ad:GEA534RF0TK35A". Just a reminder: actual zpool device is > ad6s2d. > > The new value is what is reported by diskinfo: > $ diskinfo -v ad6 > ad6 > ... > ad:GEA534RF0TK35A # Disk ident. > > $ diskinfo -v ad6s2 > ad6s2 > ... > ad:GEA534RF0TK35A # Disk ident. > > $ diskinfo -v ad6s2d > ad6s2d > ... > ad:GEA534RF0TK35A # Disk ident. > > Hmm, "indent" is reported to be the same for all three entities. > > I don't remember what diskinfo reported with pre-gpart kernel, but I > suspect that it was something different. > Could anybody please check this? (on 7.X machine without GEOM_PART). > > I quickly glimpsed through sources and it seems that this comes from > DIOCGIDENT GEOM ioctl i.e. "GEOM::ident" attribute. It seems that > geom_slice.c code has some special handling for that. Interesting. Can you try the attached patch to GPart: -- Marcel Moolenaar xcllnt@mac.com -------------- next part -------------- A non-text attachment was scrubbed... Name: gpart.diff Type: application/octet-stream Size: 1759 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20081118/4c51f9ee/gpart.obj From joeyea323 at gmail.com Fri Nov 21 16:53:16 2008 From: joeyea323 at gmail.com (Joseph Yeager) Date: Fri Nov 21 16:53:22 2008 Subject: GGatec Performance Message-ID: <44f12db00811211633w52c7b600s20e13f4255a82948@mail.gmail.com> I've been messing around ggatec lately and have noticed that I see a drastic decrease in write speed when I share out devices as opposed to files. For instance, lets say Server2 is trying to share a drive to Server1. Server2 has 2 partitions, one for the OS and the other for the share. If I do a newfs on the 2nd partition, mount it, and create a large file on the mount I can expect a slowdown of about 5-10MB/s compared to native speed (the drive writes at about 50-55MB/s natively) when writing over the network. If I were to, instead, do the same as above except dont bother mounting and creating a large file and just sharing out the device I see a major slowdown. Where I can easily get 40-50MB/s with the former method, the latter method has trouble hitting 15MB/s. Sometimes it will barely hit 5MB/s! I see two possible solutions here that I hope someone can help me with: 1. Perhaps there are some performance tuning steps I can do to alleviate this problem or perhaps this is the incorrect way to share it out. 2. Is there any way to quickly create large files? I do like this approach better as this gives me a better way to subdivide the share. The only problem is that even at over 50MB/s, dd will still take a very long time to create a 500GB file. Thanks for your help, Joe From ivoras at freebsd.org Sat Nov 22 16:48:18 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Sat Nov 22 16:48:28 2008 Subject: GGatec Performance In-Reply-To: <44f12db00811211633w52c7b600s20e13f4255a82948@mail.gmail.com> References: <44f12db00811211633w52c7b600s20e13f4255a82948@mail.gmail.com> Message-ID: Joseph Yeager wrote: > I've been messing around ggatec lately and have noticed that I see a > drastic decrease in write speed when I share out devices as opposed to > files. For instance, lets say Server2 is trying to share a drive to > Server1. Server2 has 2 partitions, one for the OS and the other for the > share. If I do a newfs on the 2nd partition, mount it, and create a large > file on the mount I can expect a slowdown of about 5-10MB/s compared to > native speed (the drive writes at about 50-55MB/s natively) when writing > over the network. If I were to, instead, do the same as above except dont > bother mounting and creating a large file and just sharing out the device I > see a major slowdown. Where I can easily get 40-50MB/s with the former > method, the latter method has trouble hitting 15MB/s. Sometimes it will > barely hit 5MB/s! I see two possible solutions here that I hope someone can > help me with: Raw drives in FreeBSD are always accessed synchronously - there is no block-level caching (and no block devices). A big file located on a usual file system with default settings will be practically always cached both for reading and for writing. Among other things, this means that a power failure will almost certainly result in a corrupted file system that is stored within that file (but the "outer" file system on the physical drive will survive). You can test this theory by mounting the file system which hosts your big file with a file system inside it as synchronous (-o sync) - you should achieve about the same low performance as accessing the raw drive (there will still be read-caching which will influence your performance). There is nothing you can do to improve this on the software level. The biggest improvement for this particular problem would be to use a faster network - so the network drive is accessed with minimal latency and mimics the performance of local drives (see also: iSCSI performance, since it's effectively the same thing on a different protocol). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20081123/bbef3a75/signature.pgp From bugmaster at FreeBSD.org Mon Nov 24 03:07:13 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 24 03:08:00 2008 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200811241107.mAOB7C7Q019898@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/128529 geom [gjournal] root FS on GEOM Journal cannot boot when jo o kern/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 that 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 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/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120231 geom [geom] GEOM_CONCAT error adding second drive 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 f 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/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/84556 geom [geom] GBDE-encrypted swap causes panic at shutdown 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 41 problems total. From avg at icyb.net.ua Wed Nov 26 13:22:48 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Nov 26 13:23:00 2008 Subject: zfs: affected by geom_(mbr|bsd) => geom_part_(mbr|bsd) ? In-Reply-To: <022C4222-63B2-4535-8B7E-0426E9CE2BEA@mac.com> References: <4911C3E9.405@icyb.net.ua> <49198A1A.3080600@icyb.net.ua> <49227875.6090902@icyb.net.ua> <93FC5F5D-91CD-450B-B08D-5C5EC5A1C880@mac.com> <4922FB81.50608@icyb.net.ua> <022C4222-63B2-4535-8B7E-0426E9CE2BEA@mac.com> Message-ID: <492DBE1F.2040501@icyb.net.ua> on 18/11/2008 21:49 Marcel Moolenaar said the following: > > On Nov 18, 2008, at 9:29 AM, Andriy Gapon wrote: > >> I just remembered that I saved old zpool.cache file before "migrating" >> the pool. >> I looked at the diff of hexdumps and there are a number of differences, >> it's hard to understand them because the file is binary (actually it >> seems to contain serialized name-value pairs), but one difference is >> prominent: >> ... >> 00000260 64 65 76 69 64 00 00 00 00 00 00 09 00 00 00 01 >> |devid...........| >> ... >> -00000270 00 00 00 15 61 64 3a 47 45 41 35 33 34 52 46 30 >> |....ad:GEA534RF0| >> -00000280 54 4b 33 35 41 73 31 73 33 00 00 00 00 00 00 28 >> |TK35As1s3......(| >> ... >> +00000270 00 00 00 11 61 64 3a 47 45 41 35 33 34 52 46 30 >> |....ad:GEA534RF0| >> +00000280 54 4b 33 35 41 00 00 00 00 00 00 28 00 00 00 28 >> |TK35A......(...(| >> ... >> >> It looks like old "devid" value is "ad:GEA534RF0TK35As1s3" and new one >> is "ad:GEA534RF0TK35A". Just a reminder: actual zpool device is ad6s2d. >> >> The new value is what is reported by diskinfo: >> $ diskinfo -v ad6 >> ad6 >> ... >> ad:GEA534RF0TK35A # Disk ident. >> >> $ diskinfo -v ad6s2 >> ad6s2 >> ... >> ad:GEA534RF0TK35A # Disk ident. >> >> $ diskinfo -v ad6s2d >> ad6s2d >> ... >> ad:GEA534RF0TK35A # Disk ident. >> >> Hmm, "indent" is reported to be the same for all three entities. >> >> I don't remember what diskinfo reported with pre-gpart kernel, but I >> suspect that it was something different. >> Could anybody please check this? (on 7.X machine without GEOM_PART). >> >> I quickly glimpsed through sources and it seems that this comes from >> DIOCGIDENT GEOM ioctl i.e. "GEOM::ident" attribute. It seems that >> geom_slice.c code has some special handling for that. > > Interesting. Can you try the attached patch to GPart: > Marcel, unfortunately the patch caused a panic. Unfortunately, again, I wasn't able to catch a proper dump, but I remembered that the panic was in g_part_done+0x16. In general, I am not sure if anything is really needed in this direction. First, I think that pjd has recently committed changes to trunk ZFS, so that it doesn't need device ids anymore and uses some metadata in the devices. Second, there is a migration path that I used - export/import of a pool. So unless this detail of backward compatibility is really needed somewhere else... -- Andriy Gapon From xcllnt at mac.com Wed Nov 26 14:55:19 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Nov 26 14:55:25 2008 Subject: zfs: affected by geom_(mbr|bsd) => geom_part_(mbr|bsd) ? In-Reply-To: <492DBE1F.2040501@icyb.net.ua> References: <4911C3E9.405@icyb.net.ua> <49198A1A.3080600@icyb.net.ua> <49227875.6090902@icyb.net.ua> <93FC5F5D-91CD-450B-B08D-5C5EC5A1C880@mac.com> <4922FB81.50608@icyb.net.ua> <022C4222-63B2-4535-8B7E-0426E9CE2BEA@mac.com> <492DBE1F.2040501@icyb.net.ua> Message-ID: On Nov 26, 2008, at 1:22 PM, Andriy Gapon wrote: > on 18/11/2008 21:49 Marcel Moolenaar said the following: >> On Nov 18, 2008, at 9:29 AM, Andriy Gapon wrote: >>> I just remembered that I saved old zpool.cache file before >>> "migrating" >>> the pool. >>> I looked at the diff of hexdumps and there are a number of >>> differences, >>> it's hard to understand them because the file is binary (actually it >>> seems to contain serialized name-value pairs), but one difference is >>> prominent: >>> ... >>> 00000260 64 65 76 69 64 00 00 00 00 00 00 09 00 00 00 01 >>> |devid...........| >>> ... >>> -00000270 00 00 00 15 61 64 3a 47 45 41 35 33 34 52 46 30 >>> |....ad:GEA534RF0| >>> -00000280 54 4b 33 35 41 73 31 73 33 00 00 00 00 00 00 28 >>> |TK35As1s3......(| >>> ... >>> +00000270 00 00 00 11 61 64 3a 47 45 41 35 33 34 52 46 30 >>> |....ad:GEA534RF0| >>> +00000280 54 4b 33 35 41 00 00 00 00 00 00 28 00 00 00 28 >>> |TK35A......(...(| >>> ... >>> >>> It looks like old "devid" value is "ad:GEA534RF0TK35As1s3" and new >>> one >>> is "ad:GEA534RF0TK35A". Just a reminder: actual zpool device is >>> ad6s2d. >>> >>> The new value is what is reported by diskinfo: >>> $ diskinfo -v ad6 >>> ad6 >>> ... >>> ad:GEA534RF0TK35A # Disk ident. >>> >>> $ diskinfo -v ad6s2 >>> ad6s2 >>> ... >>> ad:GEA534RF0TK35A # Disk ident. >>> >>> $ diskinfo -v ad6s2d >>> ad6s2d >>> ... >>> ad:GEA534RF0TK35A # Disk ident. >>> >>> Hmm, "indent" is reported to be the same for all three entities. >>> >>> I don't remember what diskinfo reported with pre-gpart kernel, but I >>> suspect that it was something different. >>> Could anybody please check this? (on 7.X machine without GEOM_PART). >>> >>> I quickly glimpsed through sources and it seems that this comes from >>> DIOCGIDENT GEOM ioctl i.e. "GEOM::ident" attribute. It seems that >>> geom_slice.c code has some special handling for that. >> Interesting. Can you try the attached patch to GPart: > > Marcel, > > unfortunately the patch caused a panic. > Unfortunately, again, I wasn't able to catch a proper dump, but I > remembered that the panic was in g_part_done+0x16. I see :-/ > In general, I am not sure if anything is really needed in this > direction. > First, I think that pjd has recently committed changes to trunk ZFS, > so that it doesn't need device ids anymore and uses some metadata in > the devices. > Second, there is a migration path that I used - export/import of a > pool. > > So unless this detail of backward compatibility is really needed > somewhere else... pjd told me that and since it was added for ZFS, I think I'll just drop it. Patching GEOM:ident this way is kinda ugly... Thanks for testing! -- Marcel Moolenaar xcllnt@mac.com From linimon at FreeBSD.org Thu Nov 27 20:53:41 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Nov 27 20:53:52 2008 Subject: kern/129245: [geom] gcache is more suitable for suffix based provider name Message-ID: <200811280453.mAS4reuf095375@freefall.freebsd.org> Old Synopsis: gcache is more suitable for suffix based provider name New Synopsis: [geom] gcache is more suitable for suffix based provider name Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: linimon Responsible-Changed-When: Fri Nov 28 04:53:03 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=129245 From salvataha1 at live.co.za Sat Nov 29 01:45:12 2008 From: salvataha1 at live.co.za (Col. Salva Taha (Rtd)) Date: Sat Nov 29 01:45:19 2008 Subject: PROPERTIES. Message-ID: <200811290931.mAT9VlHM010635@vulcan.highspd.net> Good Day, I wish to introduce myself to you.I am Col.Salva Taha a top Sudanese Goverment official who opposed the war in Dafur in my country Sudan.Due to my oppostion to the war,the goverment of my country has been persecuting me.Consequently my wife,children and I managed to enter a red cross air plane that was evacuating foreigners and we are presently in Cape Town,South Africa. We wish to invest in properties in your country with your assistance and cooperation.If you are in a good position to help my family, please send an email to the email address below indicating your desire to help my family invest the funds in your country and beyond. I urgently await your email. best regards. God bless, Col. Salva Taha (Rtd) Email:salvataha1@live.co.za From hilko.meyer at gmx.de Sat Nov 29 15:15:25 2008 From: hilko.meyer at gmx.de (Hilko Meyer) Date: Sat Nov 29 15:15:32 2008 Subject: System freeze with gvinum Message-ID: Hi, I've tried to set up a raid-5 over three disks with gvinum today with this gvinum.conf: drive sata1 device /dev/ad4 drive sata2 device /dev/ad5 drive sata3 device /dev/ad6 volume homes_raid5 plex org raid5 512k sd length 238465m drive sata1 sd length 238465m drive sata2 sd length 238465m drive sata3 volume dump_raid5 plex org raid5 512k sd length 238465m drive sata1 sd length 238465m drive sata2 sd length 238465m drive sata3 Every time I tried to run newfs on one of the volumes it stucked and the complete system freezed, so I cannot provide a coredump. The system runs 6.4-RELEASE that was compiled today. What can I do to debug this problem? Involved hardware: atapci0: ad4: 476940MB at ata2-master UDMA33 ad5: 476940MB at ata2-slave UDMA33 ad6: 476940MB at ata3-master UDMA33 BTW: That are SATA-disks. Why they are reported as UDMA33? Thanks for your help in advance. bye, Hilko From dmitry.jurasov at gmail.com Sun Nov 30 05:55:44 2008 From: dmitry.jurasov at gmail.com (Dmitry) Date: Sun Nov 30 08:11:09 2008 Subject: about pluggable disk scheduler Message-ID: <10210814530.20081130163737@gmail.com> Hello freebsd-geom, I'm a student, interested in developing pluggable disk scheduler idea. I want to know if some work is being processed and if there is need to do this work. Also I have interest in participating in Summer of Code 2009, so I would like to contact with possible mentor for further discussion. -- Best regards, Dmitry mailto:Dmitry.Jurasov@gmail.com From lulf at stud.ntnu.no Sun Nov 30 08:36:16 2008 From: lulf at stud.ntnu.no (Ulf Lilleengen) Date: Sun Nov 30 08:36:24 2008 Subject: System freeze with gvinum In-Reply-To: References: Message-ID: <20081130153558.GA2120@nobby.lan> On Sat, Nov 29, 2008 at 11:47:59PM +0100, Hilko Meyer wrote: > Hi, > > I've tried to set up a raid-5 over three disks with gvinum today with this > gvinum.conf: > > drive sata1 device /dev/ad4 > drive sata2 device /dev/ad5 > drive sata3 device /dev/ad6 > > volume homes_raid5 > plex org raid5 512k > sd length 238465m drive sata1 > sd length 238465m drive sata2 > sd length 238465m drive sata3 > volume dump_raid5 > plex org raid5 512k > sd length 238465m drive sata1 > sd length 238465m drive sata2 > sd length 238465m drive sata3 > > Every time I tried to run newfs on one of the volumes it stucked and the > complete system freezed, so I cannot provide a coredump. The system runs > 6.4-RELEASE that was compiled today. What can I do to debug this problem? > Hmm, do you have any console output before the freeze? Such as g_* messages? This might be a gvinum bug, but can also be a problem with the sata driver. > > Involved hardware: > atapci0: > ad4: 476940MB at ata2-master UDMA33 > ad5: 476940MB at ata2-slave UDMA33 > ad6: 476940MB at ata3-master UDMA33 > > BTW: That are SATA-disks. Why they are reported as UDMA33? Seems weird. Maybe there are some bios settings turning of AHCI-mode? -- Ulf Lilleengen From Hilko.Meyer at gmx.de Sun Nov 30 12:45:36 2008 From: Hilko.Meyer at gmx.de (Hilko Meyer) Date: Sun Nov 30 12:45:43 2008 Subject: System freeze with gvinum In-Reply-To: <20081130153558.GA2120@nobby.lan> References: <20081130153558.GA2120@nobby.lan> Message-ID: Ulf Lilleengen schrieb: >On Sat, Nov 29, 2008 at 11:47:59PM +0100, Hilko Meyer wrote: >> >> I've tried to set up a raid-5 over three disks with gvinum today with this >> gvinum.conf: >> >> drive sata1 device /dev/ad4 >> drive sata2 device /dev/ad5 >> drive sata3 device /dev/ad6 >> >> volume homes_raid5 >> plex org raid5 512k >> sd length 238465m drive sata1 >> sd length 238465m drive sata2 >> sd length 238465m drive sata3 >> volume dump_raid5 >> plex org raid5 512k >> sd length 238465m drive sata1 >> sd length 238465m drive sata2 >> sd length 238465m drive sata3 >> >> Every time I tried to run newfs on one of the volumes it stucked and the >> complete system freezed, so I cannot provide a coredump. The system runs >> 6.4-RELEASE that was compiled today. What can I do to debug this problem? >> >Hmm, do you have any console output before the freeze? Such as g_* messages? Unfortunately nothing. >This might be a gvinum bug, but can also be a problem with the sata driver. How can I test the sata driver? After writing the mail yesterday we used dump|restore to copy several gigabytes to ad4s1a and no problems occured in this test. >> Involved hardware: >> atapci0: >> ad4: 476940MB at ata2-master UDMA33 >> ad5: 476940MB at ata2-slave UDMA33 >> ad6: 476940MB at ata3-master UDMA33 >> >> BTW: That are SATA-disks. Why they are reported as UDMA33? >Seems weird. Maybe there are some bios settings turning of AHCI-mode? Ah, I think I know were to look for that. I'll try tomorrow. bye, Hilko From lulf at stud.ntnu.no Sun Nov 30 13:24:11 2008 From: lulf at stud.ntnu.no (Ulf Lilleengen) Date: Sun Nov 30 13:24:17 2008 Subject: System freeze with gvinum In-Reply-To: References: <20081130153558.GA2120@nobby.lan> Message-ID: <20081130222445.GA1528@carrot.studby.ntnu.no> On s?n, nov 30, 2008 at 09:18:24pm +0100, Hilko Meyer wrote: > Ulf Lilleengen schrieb: > >On Sat, Nov 29, 2008 at 11:47:59PM +0100, Hilko Meyer wrote: > >> > >> I've tried to set up a raid-5 over three disks with gvinum today with this > >> gvinum.conf: > >> > >> drive sata1 device /dev/ad4 > >> drive sata2 device /dev/ad5 > >> drive sata3 device /dev/ad6 > >> > >> volume homes_raid5 > >> plex org raid5 512k > >> sd length 238465m drive sata1 > >> sd length 238465m drive sata2 > >> sd length 238465m drive sata3 > >> volume dump_raid5 > >> plex org raid5 512k > >> sd length 238465m drive sata1 > >> sd length 238465m drive sata2 > >> sd length 238465m drive sata3 > >> > >> Every time I tried to run newfs on one of the volumes it stucked and the > >> complete system freezed, so I cannot provide a coredump. The system runs > >> 6.4-RELEASE that was compiled today. What can I do to debug this problem? > >> > >Hmm, do you have any console output before the freeze? Such as g_* messages? > > Unfortunately nothing. > > >This might be a gvinum bug, but can also be a problem with the sata driver. > > How can I test the sata driver? After writing the mail yesterday we > used dump|restore to copy several gigabytes to ad4s1a and no problems > occured in this test. Hmm, ok. Are you willing to try a patch to bring it up to 7.x gvinum? There are a few issues in 6.x that may be the cause of your problems. > > >> Involved hardware: > >> atapci0: > >> ad4: 476940MB at ata2-master UDMA33 > >> ad5: 476940MB at ata2-slave UDMA33 > >> ad6: 476940MB at ata3-master UDMA33 > >> > >> BTW: That are SATA-disks. Why they are reported as UDMA33? > >Seems weird. Maybe there are some bios settings turning of AHCI-mode? > > Ah, I think I know were to look for that. I'll try tomorrow. > > bye, > Hilko > -- Ulf Lilleengen From rick-freebsd2008 at kiwi-computer.com Sun Nov 30 15:24:47 2008 From: rick-freebsd2008 at kiwi-computer.com (Rick C. Petty) Date: Sun Nov 30 15:24:54 2008 Subject: (trivial) patch to add provider name to printed warning Message-ID: <20081130225805.GA27328@keira.kiwi-computer.com> Could someone with a commit bit (perhaps phk@) look at the following trivial patch? It can't hurt anything, since the provider name cannot be NULL here. Thanks, -- Rick C. Petty From Hilko.Meyer at gmx.de Sun Nov 30 15:32:37 2008 From: Hilko.Meyer at gmx.de (Hilko Meyer) Date: Sun Nov 30 15:32:44 2008 Subject: System freeze with gvinum In-Reply-To: <20081130222445.GA1528@carrot.studby.ntnu.no> References: <20081130153558.GA2120@nobby.lan> <20081130222445.GA1528@carrot.studby.ntnu.no> Message-ID: Ulf Lilleengen schrieb: >On s?n, nov 30, 2008 at 09:18:24pm +0100, Hilko Meyer wrote: >> Ulf Lilleengen schrieb: >> >On Sat, Nov 29, 2008 at 11:47:59PM +0100, Hilko Meyer wrote: >> >> >> >> I've tried to set up a raid-5 over three disks with gvinum today with this >> >> gvinum.conf: [...] >> >> Every time I tried to run newfs on one of the volumes it stucked and the >> >> complete system freezed, so I cannot provide a coredump. The system runs >> >> 6.4-RELEASE that was compiled today. What can I do to debug this problem? >> >> >> >Hmm, do you have any console output before the freeze? Such as g_* messages? >> >> Unfortunately nothing. >> >> >This might be a gvinum bug, but can also be a problem with the sata driver. >> >> How can I test the sata driver? After writing the mail yesterday we >> used dump|restore to copy several gigabytes to ad4s1a and no problems >> occured in this test. >Hmm, ok. Are you willing to try a patch to bring it up to 7.x gvinum? There >are a few issues in 6.x that may be the cause of your problems. Is gvinum in 7.1RC and 7.x the same? We considered to update to 7.1 before it's released anyway, because we need nfe(4). And wanted to try gvinum and zfs there. But we can test a patch against 6.4 before the big update if you want. bye, Hilko BTW: Your Reply-To: is broken. From rick-freebsd2008 at kiwi-computer.com Sun Nov 30 15:32:56 2008 From: rick-freebsd2008 at kiwi-computer.com (Rick C. Petty) Date: Sun Nov 30 15:33:02 2008 Subject: (trivial) patch to add provider name to printed warning In-Reply-To: <20081130225805.GA27328@keira.kiwi-computer.com> References: <20081130225805.GA27328@keira.kiwi-computer.com> Message-ID: <20081130233255.GA27667@keira.kiwi-computer.com> On Sun, Nov 30, 2008 at 04:58:05PM -0600, Rick C. Petty wrote: > Could someone with a commit bit (perhaps phk@) look at the following > trivial patch? It can't hurt anything, since the provider name cannot > be NULL here. Thanks, D'oh, the attachment was filtered. Here it is inline... -- Rick C. Petty --- src/sys/geom/geom_bsd.c.orig 2007-12-17 19:24:27.000000000 -0600 +++ src/sys/geom/geom_bsd.c 2008-11-30 03:09:04.000000000 -0600 @@ -136,7 +136,8 @@ } if (rawoffset != 0 && (off_t)rawoffset != ms->mbroffset) - printf("WARNING: Expected rawoffset %jd, found %jd\n", + printf("WARNING: %s expected rawoffset %jd, found %jd\n", + gp->name, (intmax_t)ms->mbroffset/dl.d_secsize, (intmax_t)rawoffset/dl.d_secsize); From lulf at stud.ntnu.no Sun Nov 30 17:16:43 2008 From: lulf at stud.ntnu.no (Ulf Lilleengen) Date: Sun Nov 30 17:16:49 2008 Subject: System freeze with gvinum In-Reply-To: References: <20081130153558.GA2120@nobby.lan> <20081130222445.GA1528@carrot.studby.ntnu.no> Message-ID: <20081201021720.GA1949@carrot.studby.ntnu.no> On man, des 01, 2008 at 12:32:22am +0100, Hilko Meyer wrote: > Ulf Lilleengen schrieb: > >On s?n, nov 30, 2008 at 09:18:24pm +0100, Hilko Meyer wrote: > >> Ulf Lilleengen schrieb: > >> >On Sat, Nov 29, 2008 at 11:47:59PM +0100, Hilko Meyer wrote: > >> >> > >> >> I've tried to set up a raid-5 over three disks with gvinum today with this > >> >> gvinum.conf: > [...] > >> >> Every time I tried to run newfs on one of the volumes it stucked and the > >> >> complete system freezed, so I cannot provide a coredump. The system runs > >> >> 6.4-RELEASE that was compiled today. What can I do to debug this problem? > >> >> > >> >Hmm, do you have any console output before the freeze? Such as g_* messages? > >> > >> Unfortunately nothing. > >> > >> >This might be a gvinum bug, but can also be a problem with the sata driver. > >> > >> How can I test the sata driver? After writing the mail yesterday we > >> used dump|restore to copy several gigabytes to ad4s1a and no problems > >> occured in this test. > >Hmm, ok. Are you willing to try a patch to bring it up to 7.x gvinum? There > >are a few issues in 6.x that may be the cause of your problems. > > Is gvinum in 7.1RC and 7.x the same? We considered to update to 7.1 > before it's released anyway, because we need nfe(4). And wanted to try > gvinum and zfs there. Yes, they are the same. > > But we can test a patch against 6.4 before the big update if you want. > It's really up to you. If you're going to upgrade anyway, it will at least save me from a little bit of work :) > bye, > Hilko > BTW: Your Reply-To: is broken. > Yeah, just noticed :) -- Ulf Lilleengen