From owner-freebsd-geom@FreeBSD.ORG Sun Oct 17 03:29:00 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65A401065673 for ; Sun, 17 Oct 2010 03:29:00 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [199.26.172.34]) by mx1.freebsd.org (Postfix) with ESMTP id 49CB18FC1D for ; Sun, 17 Oct 2010 03:29:00 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id o9H3D6sY006641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 16 Oct 2010 20:13:09 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id o9H3D61Y006640 for freebsd-geom@freebsd.org; Sat, 16 Oct 2010 20:13:06 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA07236; Sat, 16 Oct 10 20:02:14 PDT Date: Sat, 16 Oct 2010 20:01:56 -0700 From: perryh@pluto.rain.com To: freebsd-geom@freebsd.org Message-Id: <4cba6724.semecSgu9uAdne2O%perryh@pluto.rain.com> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Subdividing a gmirror X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Oct 2010 03:29:00 -0000 How does one go about subdividing a gmirror? Using the 8.1 memstick distribution, I've created a gmirror (which currently contains only one provider -- the other is to be added later), and Fixit can see /dev/mirror/gm0* once I've executed "gmirror load", but neither gpart nor fdisk seems to recognize gm0 as something on which it can operate. bsdlabel sees _something_, but it appears not to be valid. The following is a script(1) starting when I first boot into Fixit# from the memstick. I've inserted a blank line ahead of each command to simplify skipping over output that may not be relevant, and I've inserted some commentary (lines starting with !). The disk already contains the gmirror metadata (created during a previous attempt). Script started on Mon Oct 4 03:42:54 2010 Fixit# dmesg Copyright (c) 1992-2010 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 8.1-RELEASE #0: Mon Jul 19 02:55:53 UTC 2010 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (731.47-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Family = 6 Model = 8 Stepping = 3 Features=0x383fbff real memory = 536870912 (512 MB) avail memory = 506056704 (482 MB) ACPI APIC Table: ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, f00000 (3) failed acpi0: reservation of 1000000, 1ef9e000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xf4000000-0xf5ffffff,0xfcffc000-0xfcffffff,0xfc000000-0xfc7fffff irq 16 at device 0.0 on pci1 pcib2: at device 30.0 on pci0 pci2: on pcib2 xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xdc80-0xdcff mem 0xf8fffc00-0xf8fffc7f irq 16 at device 4.0 on pci2 miibus0: on xl0 xlphy0: <3c905C 10/100 internal PHY> PHY 24 on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:b0:d0:22:5a:14 xl0: [ITHREAD] pci2: at device 6.0 (no driver attached) atapci0: port 0xdc70-0xdc7f,0xdc50-0xdc5f,0xdc30-0xdc3f,0xdc10-0xdc1f,0xd8e0-0xd8ff,0xd400-0xd4ff irq 19 at device 11.0 on pci2 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] pcib3: at device 14.0 on pci2 pci3: on pcib3 ahc0: port 0xec00-0xecff mem 0xfafff000-0xfaffffff irq 18 at device 10.0 on pci3 ahc0: [ITHREAD] aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs ahc1: port 0xe800-0xe8ff mem 0xfaffe000-0xfaffefff irq 19 at device 10.1 on pci3 ahc1: [ITHREAD] aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] uhci0: port 0xff80-0xff9f irq 19 at device 31.2 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x2f00 usbus0: on uhci0 pci0: at device 31.3 (no driver attached) atrtc0: port 0x70-0x7f irq 8 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] ppc0: port 0x378-0x37f,0x778-0x77f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xcdfff,0xce000-0xcffff pnpid ORM0000 on isa0 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 731469967 Hz quality 800 Timecounters tick every 1.000 msec md0: Preloaded image 4423680 bytes at 0xc0fb5504 usbus0: 12Mbps Full Speed USB v1.0 ad0: 305245MB at ata0-master UDMA66 ugen0.1: at usbus0 uhub0: on usbus0 ad1: 32253MB at ata0-slave UDMA66 uhub0: 2 ports with 2 removable, self powered device_attach: afd0 attach returned 6 ugen0.2: at usbus0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x0000 acd0: CDROM at ata1-slave PIO4 ad4: 61136MB at ata2-master UDMA100 SATA 1.5Gb/s acd1: DVDR at ata3-master UDMA66 SATA 1.5Gb/s ad8: 305245MB at ata4-master UDMA133 umass0:2:0:-1: Attached to scbus2 da0 at ahc0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit) da0: Command Queueing enabled da0: 8683MB (17783249 512 byte sectors: 255H 63S/T 1106C) da1 at umass-sim0 bus 0 scbus2 target 0 lun 0 da1: Removable Direct Access SCSI-2 device da1: 1.000MB/s transfers da1: 960MB (1967616 512 byte sectors: 64H 32S/T 960C) GEOM: ad0s2: geometry does not match label (255h,63s != 16h,63s). GEOM: ad8s2: geometry does not match label (255h,63s != 16h,63s). GEOM: da1: geometry does not match label (255h,63s != 64h,32s). GEOM: da1: media size does not match label. Trying to mount root from ufs:/dev/md0 ! make *.ko available Fixit# ln -s /dist/boot/kernel /boot Fixit# gmirror load ! see what "gmirror load" appended to dmesg. I know from watching ! the console that it was only 3 lines, so "tail -5" will provide ! 2 lines of overlap with the previous listing. Fixit# dmesg | tail -5 GEOM: da1: geometry does not match label (255h,63s != 64h,32s). GEOM: da1: media size does not match label. Trying to mount root from ufs:/dev/md0 GEOM_MIRROR: Device mirror/gm0 launched (1/1). GEOM_MIRROR: Cannot add disk ad0s2a to gm0 (error=17). Fixit# ls -la /dev/mirror total 1 dr-xr-xr-x 2 root 0 512 Oct 4 03:44 . dr-xr-xr-x 9 root 0 512 Oct 4 03:42 .. crw-r----- 1 root operator 0, 80 Oct 4 03:43 gm0 crw-r----- 1 root operator 0, 125 Oct 4 03:43 gm0a crw-r----- 1 root operator 0, 126 Oct 4 03:43 gm0b ! so the mirror does exist, despite the "Cannot add" message. Fixit# bsdlabel /dev/mirror/gm0 # /dev/mirror/gm0: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 619907518 0 4.2BSD 0 0 0 b: 2097152 619907518 swap c: 622004670 0 unused 0 0 # "raw" part, don't edit partition a: partition extends past end of unit partition b: offset past end of unit partition b: partition extends past end of unit partition c: partition extends past end of unit bsdlabel: partition c doesn't cover the whole unit! bsdlabel: An incorrect partition c may cause problems for standard system utilities ! evidently gm0 does not contain a _valid_ bsdlabel. ! Again, with -A, just in case the additional info is useful. Fixit# bsdlabel -A /dev/mirror/gm0 # /dev/mirror/gm0: type: ESDI disk: ad0s2 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 38913 sectors/unit: 625142448 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 619907518 0 4.2BSD 0 0 0 b: 2097152 619907518 swap c: 622004670 0 unused 0 0 # "raw" part, don't edit bsdlabel: partition c doesn't cover the whole unit! bsdlabel: An incorrect partition c may cause problems for standard system utilities !note that this time there were no complaints about partitions a & b. !dunno if this is of any significance. Fixit# gpart show gm0 gpart: No such geom: gm0. Fixit# gpart show /dev/mirror/gm0 gpart: No such geom: /dev/mirror/gm0. ! So gm0 evidently doesn't have a valid gpart label either. ! What is defining gm0a and gm0b, if it is neither a gpart nor a bsdlabel? ! Try to reslice & label gm0, which "should" appear to be a disk device Fixit# fdisk -v -B -I /dev/mirror/gm0 ******* Working on device /dev/mirror/gm0 ******* parameters extracted from in-core disklabel are: cylinders=38587 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=38587 heads=255 sectors/track=63 (16065 blks/cyl) Information from DOS bootblock is: 1: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 619900092 (302685 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 698/ head 254/ sector 63 2: 3: 4: fdisk: Class not found ! What does this mean? Fixit# ls -la /dev/mirror total 1 dr-xr-xr-x 2 root 0 512 Oct 4 03:44 . dr-xr-xr-x 9 root 0 512 Oct 4 03:42 .. crw-r----- 1 root operator 0, 80 Oct 4 03:46 gm0 crw-r----- 1 root operator 0, 125 Oct 4 03:46 gm0a crw-r----- 1 root operator 0, 126 Oct 4 03:46 gm0b ! The partitioning seems unchanged, but apparently something was ! written (since the timestamps have changed). No telling what it ! may have been. Fixit# ^D Script done on Mon Oct 4 03:48:31 2010 From owner-freebsd-geom@FreeBSD.ORG Sun Oct 17 23:24:34 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EA4C1065670 for ; Sun, 17 Oct 2010 23:24:34 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1D0D78FC2B for ; Sun, 17 Oct 2010 23:24:33 +0000 (UTC) Received: by vws1 with SMTP id 1so179485vws.13 for ; Sun, 17 Oct 2010 16:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=XfrikdXGgcMGCzV+8duHR7MfwLDmCnnHJ6Z3FRrelcs=; b=TNbgzcXxm3iAtcVQqkHycyHVylebXFflJ5MbXbXMCTIxR2+U+DQQ0abXeJ9NcNJhZi cyubCkxOYxFc4JkBL6Yo4p0MglR1jWt5NiJhxFBgqsR2RFI5aH6TuzzJduOv37MuLNya otmRzfTfd+fKYeKtYiAU2Ks99M1DTxZHkN2sc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=O0sT3gsuaV9896wRImI/SDKHr1r3Zy1S+7++WYMavVhsqGMDOncqVfEDdKlFer0glL S2oXY8E5aPSwgAo5o61ZK0yNkP1i9Sa+y1HDLvxUn5bJbdvr1ao36lLS+qemZdjIrr5i YI3mVo9mlrUTT0f3pOmMm8kj/H6V/3sSTj5lc= MIME-Version: 1.0 Received: by 10.220.191.205 with SMTP id dn13mr912627vcb.271.1287356361194; Sun, 17 Oct 2010 15:59:21 -0700 (PDT) Received: by 10.220.193.138 with HTTP; Sun, 17 Oct 2010 15:59:21 -0700 (PDT) Date: Sun, 17 Oct 2010 18:59:21 -0400 Message-ID: From: grarpamp To: freebsd-geom@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: GELI XTS X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Oct 2010 23:24:34 -0000 Is this headed/ready for RELENG_8? Will be initializing a good sized pile of disk before long and was hoping to go with XTS, etc. Also, in general, is there any sort of third party crypto/implementation review on geli and the related kernel crypto bits? Thanks. /head/sys/geom/eli/g_eli_crypto.c ... Revision 213070 etc Modified Thu Sep 23 11:58:36 2010 UTC (3 weeks, 3 days ago) by pjd Add support for AES-XTS. This will be the default now. Implement switching of data encryption key every 2^20 blocks. This ensures the same encryption key won't be used for more than 2^20 blocks (sectors). This will be the default now. MFC after: 1 week /head/sbin/geom/class/eli/geom_eli.c /head/sbin/geom/class/eli/geli.8 ... Revision 213172 etc Modified Sat Sep 25 17:38:57 2010 UTC (3 weeks, 1 day ago) by pjd - Add support for loading passphrase from a file (-J and -j options). This is especially useful for things like installers, where regular geli prompt can't be used. - Add support for specifing multiple -K or -k options, so there is no need to cat all keyfiles and read them from standard input. MFC after: 2 weeks From owner-freebsd-geom@FreeBSD.ORG Mon Oct 18 00:22:07 2010 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11BB0106564A; Mon, 18 Oct 2010 00:22:07 +0000 (UTC) (envelope-from arundel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 01F398FC08; Mon, 18 Oct 2010 00:22:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9I0M6Y7030401; Mon, 18 Oct 2010 00:22:06 GMT (envelope-from arundel@freefall.freebsd.org) Received: (from arundel@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9I0M6QR030397; Mon, 18 Oct 2010 00:22:06 GMT (envelope-from arundel) Date: Mon, 18 Oct 2010 00:22:06 GMT Message-Id: <201010180022.o9I0M6QR030397@freefall.freebsd.org> To: gcooper@FreeBSD.org, arundel@FreeBSD.org, freebsd-geom@FreeBSD.org From: arundel@FreeBSD.org Cc: Subject: Re: bin/144521: [geom] geom(8) tool parsing non-subclass command broken X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 00:22:07 -0000 Synopsis: [geom] geom(8) tool parsing non-subclass command broken State-Changed-From-To: feedback->closed State-Changed-By: arundel State-Changed-When: Mon Oct 18 00:12:33 UTC 2010 State-Changed-Why: I'm closing this PR for the following reason: Taking the current semantics of geom into account this PR doesn't document any bug, but geom's normal behavior. For any sub-class that is not loaded, a standard help output gets generated. although something like 'geom --help help' sure looks strange, it would very well be possible to have geom load "/boot/kernel/geom_--help.ko". Of course one could argue if the current semantics of geom are the best solution, but that should rather be discussed on freebsd-geom@. http://www.freebsd.org/cgi/query-pr.cgi?pr=144521 From owner-freebsd-geom@FreeBSD.ORG Mon Oct 18 05:55:00 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDFD61065697; Mon, 18 Oct 2010 05:55:00 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward2.mail.yandex.net (forward2.mail.yandex.net [77.88.46.7]) by mx1.freebsd.org (Postfix) with ESMTP id 61F178FC18; Mon, 18 Oct 2010 05:55:00 +0000 (UTC) Received: from smtp4.mail.yandex.net (smtp4.mail.yandex.net [77.88.46.104]) by forward2.mail.yandex.net (Yandex) with ESMTP id 72E4738A8B29; Mon, 18 Oct 2010 09:54:58 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1287381298; bh=fQn8ZmY90wZ1Q966ojBCWgqFJ0JlSIYDNFJYqrIG4EU=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=v8XkGaZfhyacg1sa3ZN62HeN8kgR92ynMBGv6bVoZWwqs5OpywVuRyK6/2/rImxXq 7gO4w/9tQDhWuvj+2aOqw6aknV5U4mE4wHJGUM38RmF2hfpNKdkF+9gv8VWpa361XE IV5jTnRkGsYTyhpRytCDLnQuLxzSbiKgPGsjTBNM= Received: from [127.0.0.1] (ns.kirov.so-ups.ru [77.72.136.145]) by smtp4.mail.yandex.net (Yandex) with ESMTPSA id 1360C1280A5; Mon, 18 Oct 2010 09:54:58 +0400 (MSD) Message-ID: <4CBBE12C.1010809@yandex.ru> Date: Mon, 18 Oct 2010 09:54:52 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Marcel Moolenaar References: <4CB850CC.4040206@yandex.ru> <4CB8587F.3010401@yandex.ru> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig511D3F75724D373865FBD5A7" X-Yandex-TimeMark: 1287381298 X-Yandex-Spam: 1 X-Yandex-Front: smtp4.mail.yandex.net Cc: Pawel Jakub Dawidek , Alexander Motin , Marcel Moolenaar , Konstantin Belousov , freebsd-geom@freebsd.org Subject: Re: [RFC][patch] GPT recovering support X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 05:55:00 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig511D3F75724D373865FBD5A7 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 15.10.2010 20:15, Marcel Moolenaar wrote: > It's better to implement a force option to destroy that forces > a scheme to be destroyed in a way that prevents undo. This > allows you to (effectively) wipe sectors and start over. This > is exactly what you want if you're stuck with a detected scheme > that is corrupt to the point that you can't do anything with > it. Last time you said that user-space implementation of "destroy -F" is what you want ;) > It would be good if you can list the corruption cases that are > being handled and how you recover.=20 Do you mean list them in man page or print what is corrupt from gpart(8)? --=20 WBR, Andrey V. Elsukov --------------enig511D3F75724D373865FBD5A7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJMu+ExAAoJEAHF6gQQyKF6S3kIAIKzuPlJsxJ4s0XJQYhF6BTL EviTRa7mZfWyu/dhjyJSp2T/eFTIg9W6DBlPssjFZov/fUjSsYstCXEgQbwR4T7t DxteofoepM5SRJ7BQyYOagiVXlXEItiYdw+3WlCAcNqaTGc5Wm7E1Z4sH+ogn8in G2lqEAigFMAwV0JU9dCox+BjZzGRpOK4MnKQqP1wFAA4T8sFTRgvFXePInhiO1Yb nysI/Ys8UweQry6YIwduDZq5zfBV7bLwvtReAjDOut2ymM7VL4AowI3ml/qYBPK7 7kuypEQCCHt5aBO6pOU3V9XJhJWMMO1uBUZeAELJzBMBBakpgH0+Bg6L2jHDBAo= =dMVp -----END PGP SIGNATURE----- --------------enig511D3F75724D373865FBD5A7-- From owner-freebsd-geom@FreeBSD.ORG Mon Oct 18 11:06:58 2010 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B87C1065695 for ; Mon, 18 Oct 2010 11:06:58 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 58A018FC2E for ; Mon, 18 Oct 2010 11:06:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9IB6wBS029330 for ; Mon, 18 Oct 2010 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9IB6v1B029328 for freebsd-geom@FreeBSD.org; Mon, 18 Oct 2010 11:06:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 18 Oct 2010 11:06:57 GMT Message-Id: <201010181106.o9IB6v1B029328@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-geom@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 11:06:58 -0000 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 bin/151252 geom [geom] libgeom(3) manual page contains broken link in o kern/150858 geom [geom] [geom_label] [patch] glabel(8) is not compatibl o kern/150626 geom [geom] [gjournal] gjournal(8) destroys label o kern/150555 geom [geom] gjournal unusable on GPT partitions o kern/150334 geom [geom] [udf] [patch] geom label does not support UDF o kern/149762 geom volume labels with rogue characters o bin/149215 geom [panic] [geom_part] gpart(8): Delete linux's slice via o kern/147852 geom [geom] [panic] graid3 panic: wrong offset 16384 for se o kern/147851 geom [geom] [panic] graid3 panic: g_read_data: invalid leng o kern/147667 geom [gmirror] Booting with one component of a gmirror, the o kern/147664 geom [geom] [patch] Add the ability to create linux and fat o kern/145818 geom [geom] geom_stat_open showing cached information for n o kern/145042 geom [geom] System stops booting after printing message "GE o kern/144962 geom [geom] panic when accessing GPT disk with a large numb o kern/144905 geom [geom][geom_part] panic in gpart_ctlreq when unpluggin o kern/143455 geom gstripe(8) in RELENG_8 (31st Jan 2010) broken o kern/142563 geom [geom] [hang] ioctl freeze in zpool f kern/142365 geom [geom] FreeBSD RAID1 (gmirror) is much slower than Lin o kern/141740 geom [geom] gjournal(8): g_journal_destroy concurrent error s kern/141235 geom [geom_part] 8.0 no longer provides /dev entries for al o kern/140352 geom [geom] gjournal + glabel not working o kern/135898 geom [geom] Severe filesystem corruption - large files or l o kern/134922 geom [gmirror] [panic] kernel panic when use fdisk on disk o kern/134113 geom [geli] Problem setting secondary GELI key o kern/134044 geom [geom] gmirror(8) overwrites fs with stale data from r o kern/133931 geom [geli] [request] intentionally wrong password to destr o bin/132845 geom [geom] [patch] ggated(8) does not close files opened a o kern/132273 geom glabel(8): [patch] failing on journaled partition f kern/132242 geom [gmirror] gmirror.ko fails to fully initialize o kern/131353 geom [geom] gjournal(8) kernel lock p docs/130548 geom [patch] gjournal(8) man page is missing sysctls o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid f kern/128276 geom [gmirror] machine lock up when gmirror module is used o kern/127420 geom [geom] [gjournal] [panic] Journal overflow on gmirrore 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/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123122 geom [geom] GEOM / gjournal kernel lock o kern/122738 geom [geom] gmirror list "losts consumers" after gmirror de f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120091 geom [geom] [geli] [gjournal] geli does not prompt for pass o kern/115856 geom [geli] ZFS thought it was degraded when it should have o kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile f kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad 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/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 o kern/88601 geom [geli] geli cause kernel panic under heavy disk usage o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu o 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 64 problems total. From owner-freebsd-geom@FreeBSD.ORG Mon Oct 18 11:13:43 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D2FA106566B for ; Mon, 18 Oct 2010 11:13:43 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 02EE98FC18 for ; Mon, 18 Oct 2010 11:13:43 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1P7nev-0009Um-OQ; Mon, 18 Oct 2010 12:13:41 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P7nev-000G04-NW; Mon, 18 Oct 2010 12:13:41 +0100 Date: Mon, 18 Oct 2010 12:13:41 +0100 Message-Id: To: freebsd-geom@freebsd.org, perryh@pluto.rain.com In-Reply-To: <4cba6724.semecSgu9uAdne2O%perryh@pluto.rain.com> From: Pete French Cc: Subject: Re: Subdividing a gmirror X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 11:13:43 -0000 > Using the 8.1 memstick distribution, I've created a gmirror (which > currently contains only one provider -- the other is to be added > later), and Fixit can see /dev/mirror/gm0* once I've executed > "gmirror load", but neither gpart nor fdisk seems to recognize gm0 > as something on which it can operate. bsdlabel sees _something_, > but it appears not to be valid. try this... diskabel -w /dev/mirror/gm0 That will write a disk label to the mirrored drive, and you can then editit it using disklabel -e /dev/mirror/gm0 to add your subdividions. -pete. From owner-freebsd-geom@FreeBSD.ORG Tue Oct 19 18:15:42 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A283B106566C; Tue, 19 Oct 2010 18:15:42 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward10.mail.yandex.net (forward10.mail.yandex.net [77.88.61.49]) by mx1.freebsd.org (Postfix) with ESMTP id 346F98FC18; Tue, 19 Oct 2010 18:15:41 +0000 (UTC) Received: from smtp8.mail.yandex.net (smtp8.mail.yandex.net [77.88.61.54]) by forward10.mail.yandex.net (Yandex) with ESMTP id 5727F1F50571; Tue, 19 Oct 2010 22:15:40 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1287512140; bh=uSAsLV3CSsdfWW6v/bZUkLu2OVhqyZ2uuiWGBun5lKU=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=SVF9DJt9UGP2VX5bJ6raxYX/iYfu11iJo1O9pJ+36/yU92DPwY4363dS7OY4m1Npi mFRkSKRIbRVx3n0lmbsNo7Kxd7ZVhD9YLBxAyxieBR/7d53ewYtE2tBWVwSLm8wng/ hl8Bbgt5oIhhtiDjUK7nsvnjMs8TNpY7qDtBJGYg= Received: from [10.43.163.197] (nat-77-30.kirovnet.ru [92.39.77.30]) by smtp8.mail.yandex.net (Yandex) with ESMTPSA id CB33F202809D; Tue, 19 Oct 2010 22:15:39 +0400 (MSD) Message-ID: <4CBDE012.8030000@yandex.ru> Date: Tue, 19 Oct 2010 22:14:42 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100925 Thunderbird/3.1.4 MIME-Version: 1.0 To: Marcel Moolenaar References: <4CB850CC.4040206@yandex.ru> <4CB8587F.3010401@yandex.ru> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD80D9AA90D326A186800A0AD" X-Yandex-TimeMark: 1287512140 X-Yandex-Spam: 1 X-Yandex-Front: smtp8.mail.yandex.net Cc: Konstantin Belousov , Alexander Motin , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-geom@freebsd.org Subject: Re: [RFC][patch] GPT recovering support X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 18:15:42 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD80D9AA90D326A186800A0AD Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 15.10.2010 20:15, Marcel Moolenaar wrote: > It's better to implement a force option to destroy that forces > a scheme to be destroyed in a way that prevents undo. This > allows you to (effectively) wipe sectors and start over. This > is exactly what you want if you're stuck with a detected scheme > that is corrupt to the point that you can't do anything with I rewrite forced destroying. Now it does all work in kernel. http://people.freebsd.org/~ae/gpart_recover_20101019.diff > It would be good if you can list the corruption cases that are > being handled and how you recover. While we need to be friendly > to the GEOM flexibility, we do need to respect the GPT spec > to the extend that we remain compatible. 1. Wiped first several sectors. //------------------------------------------------------------ # truncate -s 100m disk # mdconfig -f disk md0 # gpart create -s gpt md0 md0 created # gpart add -t freebsd md0 md0s1 added # gpart show md0 =3D> 34 204733 md0 GPT (100M) 34 204733 1 freebsd (100M) # dd if=3D/dev/zero of=3D/dev/md0 bs=3D512 count=3D10 10+0 records in 10+0 records out 5120 bytes transferred in 0.169473 secs (30211 bytes/sec) # gpart show md0 gpart: No such geom: md0. // First of we should rewrite PMBR. # dd if=3D/boot/pmbr of=3D/dev/md0 1+0 records in 1+0 records out 512 bytes transferred in 0.046906 secs (10915 bytes/sec) GEOM: md0: the primary GPT table is corrupt or invalid. GEOM: md0: using the secondary instead -- recovery strongly advised. # gpart show md0 =3D> 34 204733 md0 GPT (100M) [CORRUPT] 34 204733 1 freebsd (100M) # gpart status md0 Name Status Components md0s1 CORRUPT md0 // Now we can recover it # gpart recover md0 md0 recovered # gpart show md0 =3D> 34 204733 md0 GPT (100M) 34 204733 1 freebsd (100M) //------------------------------------------------------------ 2. Wiped last several sectors. //------------------------------------------------------------ # gpart list md0 | grep last last: 204766 # dd if=3D/dev/zero of=3D/dev/md0 bs=3D512 oseek=3D204767 dd: /dev/md0: end of device 34+0 records in 33+0 records out 16896 bytes transferred in 0.345195 secs (48946 bytes/sec) GEOM: md0: the secondary GPT table is corrupt or invalid. GEOM: md0: using the primary only -- recovery suggested. # gpart show md0 =3D> 34 204733 md0 GPT (100M) [CORRUPT] 34 204733 1 freebsd (100M) // We can recover this GPT again, also we can destroy it. // But we can not modify it. # gpart delete -i 1 md0 gpart: table 'md0' is corrupt: Operation not permitted # gpart modify -i 1 -l TEST -f x md0 gpart: table 'md0' is corrupt: Operation not permitted # gpart destroy md0 gpart: Device busy # gpart destroy -F md0 md0 destroyed # gpart show md0 gpart: No such geom: md0. //------------------------------------------------------------ 3. Changed mediasize. //------------------------------------------------------------ # gpart create -s gpt md0 md0 created # gpart add -t freebsd md0 md0s1 added # gpart show md0 =3D> 34 204733 md0 GPT (100M) 34 204733 1 freebsd (100M) # mdconfig -du 0 # truncate -s +10m disk # mdconfig -f disk md0 GEOM: md0: the secondary GPT header is not in the last LBA. # gpart show md0 =3D> 34 204733 md0 GPT (110M) [CORRUPT] 34 204733 1 freebsd (100M) // Secondary GPT header must be in the last LBA. // When it is not here you can lost GPT if primary copy will // become corrupt. Also you may want to extend your table to // all mediasize. # gpart list md0 | grep last last: 204766 # gpart recover md0 md0 recovered # gpart list md0 | grep last last: 225246 # gpart show md0 =3D> 34 225213 md0 GPT (110M) 34 204733 1 freebsd (100M) 204767 20480 - free - (10M) //------------------------------------------------------------ 4. As the side effect now some of tasted copies of the same table will be read-only. //------------------------------------------------------------ # gpart destroy -F md0 md0 destroyed # glabel label -v TEST md0 Metadata value stored on md0. Done. # gpart create -s gpt label/TEST label/TEST created # gpart show =3D> 34 225212 label/TEST GPT (110M) 34 225212 - free - (110M) =3D> 34 225212 md0 GPT (110M) [CORRUPT] 34 225212 - free - (110M) # gpart add -t freebsd-ufs md0 gpart: table 'md0' is corrupt: Operation not permitted # gpart add -t freebsd-ufs label/TEST label/TESTp1 added # gpart show =3D> 34 225212 label/TEST GPT (110M) 34 225212 1 freebsd-ufs (110M) //------------------------------------------------------------ Any comments? --=20 WBR, Andrey V. Elsukov --------------enigD80D9AA90D326A186800A0AD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBAgAGBQJMveAaAAoJEAHF6gQQyKF6GPMIAIaW+GryGdicbY6oSGtOfIAP vw5HcAFz7/Fnlljc2cZj2FiAG5nZJz8QFK5Dy18Oe5u4fKP0//vWmaioT9dUnZqc 9PPxdQQbqP2WWdiUGfX825lOINRF0NsXyywZoQFmL9OsxAaKA8bTv5opG1vxODPQ E1Xnw3komFlK0Oq1txbDR5/OVxvQmcaBJGMNroBifGszObnqdiYygrPlg7A9NqXH tx38JlYqa0tDBdW0Ff5miif/OVI98PKYgqe2SqRuKVJwlsFardF75R6VXG5K9IGQ OQop86PLZiROwnfREIudnmbcWl0FnpPSKWn8oBj6hy2LIE4iMHWY3ngmbilJ2P4= =fET1 -----END PGP SIGNATURE----- --------------enigD80D9AA90D326A186800A0AD-- From owner-freebsd-geom@FreeBSD.ORG Thu Oct 21 17:43:11 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23A02106564A; Thu, 21 Oct 2010 17:43:11 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by mx1.freebsd.org (Postfix) with ESMTP id D072C8FC12; Thu, 21 Oct 2010 17:43:10 +0000 (UTC) Received: from a91-153-123-205.elisa-laajakaista.fi (a91-153-123-205.elisa-laajakaista.fi [91.153.123.205]) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id 1F7041397C0; Thu, 21 Oct 2010 20:43:03 +0300 (EEST) Date: Thu, 21 Oct 2010 20:43:01 +0300 From: Jaakko Heinonen To: Alexander Motin Message-ID: <20101021174301.GA1381@a91-153-123-205.elisa-laajakaista.fi> References: <4C4ED619.7050305@FreeBSD.org> <27237.1280241532@critter.freebsd.dk> <4C4F171C.9010106@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4C4F171C.9010106@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Marius =?utf-8?Q?N=C3=BCnnerich?= , Poul-Henning Kamp , freebsd-geom@freebsd.org Subject: Re: Hyperactive g_event thread X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 17:43:11 -0000 Hi, On 2010-07-27, Alexander Motin wrote: > Marius Nünnerich wrote: > > On Tue, Jul 27, 2010 at 18:07, Marius Nünnerich wrote: > >> I was running with a patch that removed the timeout for a while like 2 > >> years ago. Albeit not with high load. Worked fine at that time, I will > >> search for the patch when I'm back home later today. > >> > > Here it is: > > http://lists.freebsd.org/pipermail/freebsd-geom/2008-December/003200.html > > The mail is quite old now, I don't know if the patch still applies. http://nuenneri.ch/freebsd/geom_tl2.patch > Yes, I was thinking about something like that. Patch mostly applies now > and even builds. May be I would just put there sx_sleep() instead if > msleep(), as topology_lock is sx. > > Could somebody to review this and tell how correct is to not drop > topology lock between events handling and could there be places where > g_wait_event woken without holding topology_lock? I looked at this patch. g_post_event_x() and possibly g_orphan_provider() may wake g_wait_event up without holding the topology lock. g_do_wither() also lacks an assert for the lock although I guess that it's always held there. Thus I don't consider the patch being correct. I drafted a patch to use g_eventlock instead to protect against losing wakeups: http://people.freebsd.org/~jh/patches/geom-eventproc-sleep.diff Reviews and/or testing will be welcomed. -- Jaakko From owner-freebsd-geom@FreeBSD.ORG Fri Oct 22 09:56:59 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 475081065694 for ; Fri, 22 Oct 2010 09:56:59 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id F25488FC08 for ; Fri, 22 Oct 2010 09:56:58 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1P9EMs-00045B-1s for freebsd-geom@freebsd.org; Fri, 22 Oct 2010 11:56:58 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Oct 2010 11:56:58 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Oct 2010 11:56:58 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Fri, 22 Oct 2010 11:56:53 +0200 Lines: 20 Message-ID: References: <4C4ED619.7050305@FreeBSD.org> <27237.1280241532@critter.freebsd.dk> <4C4F171C.9010106@FreeBSD.org> <20101021174301.GA1381@a91-153-123-205.elisa-laajakaista.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.12) Gecko/20101018 Thunderbird/3.0.8 In-Reply-To: <20101021174301.GA1381@a91-153-123-205.elisa-laajakaista.fi> X-Enigmail-Version: 1.0.1 Subject: Re: Hyperactive g_event thread X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 09:56:59 -0000 On 10/21/10 19:43, Jaakko Heinonen wrote: > I drafted a patch to use g_eventlock instead to protect against losing > wakeups: > > http://people.freebsd.org/~jh/patches/geom-eventproc-sleep.diff > > Reviews and/or testing will be welcomed. Isn't this sequence: - mtx_unlock(&g_eventlock); wakeup(&g_wait_event); + mtx_unlock(&g_eventlock); too racy? It is possible, especially if something changes in scheduling or the wakeup() implementation, and on single-CPU machines, that the woken thread could run and then encounter the lock not yet released, leading to more lock waiting. From owner-freebsd-geom@FreeBSD.ORG Fri Oct 22 18:46:52 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 223D11065674 for ; Fri, 22 Oct 2010 18:46:52 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by mx1.freebsd.org (Postfix) with ESMTP id CCEBF8FC17 for ; Fri, 22 Oct 2010 18:46:51 +0000 (UTC) Received: from a91-153-123-205.elisa-laajakaista.fi (a91-153-123-205.elisa-laajakaista.fi [91.153.123.205]) by gw02.mail.saunalahti.fi (Postfix) with SMTP id 20E9413956A; Fri, 22 Oct 2010 21:46:48 +0300 (EEST) Date: Fri, 22 Oct 2010 21:46:46 +0300 From: Jaakko Heinonen To: Ivan Voras Message-ID: <20101022184645.GA1381@a91-153-123-205.elisa-laajakaista.fi> References: <4C4ED619.7050305@FreeBSD.org> <27237.1280241532@critter.freebsd.dk> <4C4F171C.9010106@FreeBSD.org> <20101021174301.GA1381@a91-153-123-205.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-geom@freebsd.org Subject: Re: Hyperactive g_event thread X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 18:46:52 -0000 On 2010-10-22, Ivan Voras wrote: > Isn't this sequence: > > - mtx_unlock(&g_eventlock); > wakeup(&g_wait_event); > + mtx_unlock(&g_eventlock); > > too racy? It is possible, especially if something changes in scheduling > or the wakeup() implementation, and on single-CPU machines, that the > woken thread could run and then encounter the lock not yet released, > leading to more lock waiting. As far as I have understood this is the normal way to protect against losing wakeups, no? wakeup(9) marks the sleeping process runnable and removes it from the sleep queue but doesn't force a context switch immediately. Thus increased lock contention would happen only if a context switch happens between wakeup() and mtx_unlock(). I don't see this a problem but please correct me if I am wrong. -- Jaakko From owner-freebsd-geom@FreeBSD.ORG Fri Oct 22 20:57:41 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60CCF1065670 for ; Fri, 22 Oct 2010 20:57:41 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 14CAB8FC0A for ; Fri, 22 Oct 2010 20:57:40 +0000 (UTC) Received: by yxl31 with SMTP id 31so1045591yxl.13 for ; Fri, 22 Oct 2010 13:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=rmO7Pld4vD83LHGwJVnMhFND9TzqkpSTM1oad6sepok=; b=wMOfg7a/uKghjXvSHvXdlhhPHCOF+1nc7pjwkl4IjEXbk3z5hkLBdFHPGON6Mh+fUF D1yW75WLLB8JQGwwO6le6EAC6Zi1dsuPsJIDtE/n7AaKHPuNsjfuuuM+Ieif8QfvV0v9 Kozz/6MiQrq2BghQBqNRh04smACnfI4ONmoLQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=u7Ek1/IfJlurAfZw+Th+PG175HWuVqiazVFpLl52t/k6pQMGBaf/PXpK/Wgbuwggru i/uinj7ThyeyCiamyey/BpPEe9ir43hp3EOxGanTL0slTGCP5Amw4R40NCOwVL7Ffhsz RpeGCbN0sZZdsdwUt7zGX0RCkbadil3ZOdsOo= Received: by 10.229.236.203 with SMTP id kl11mr2727196qcb.204.1287779535574; Fri, 22 Oct 2010 13:32:15 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.80.5 with HTTP; Fri, 22 Oct 2010 13:31:34 -0700 (PDT) In-Reply-To: <20101022184645.GA1381@a91-153-123-205.elisa-laajakaista.fi> References: <4C4ED619.7050305@FreeBSD.org> <27237.1280241532@critter.freebsd.dk> <4C4F171C.9010106@FreeBSD.org> <20101021174301.GA1381@a91-153-123-205.elisa-laajakaista.fi> <20101022184645.GA1381@a91-153-123-205.elisa-laajakaista.fi> From: Ivan Voras Date: Fri, 22 Oct 2010 22:31:34 +0200 X-Google-Sender-Auth: T3ONjzIROGdgD8Y8PmaluIrxSzU Message-ID: To: Jaakko Heinonen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-geom@freebsd.org Subject: Re: Hyperactive g_event thread X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 20:57:41 -0000 On 22 October 2010 20:46, Jaakko Heinonen wrote: > On 2010-10-22, Ivan Voras wrote: >> Isn't this sequence: >> >> - =C2=A0 =C2=A0 mtx_unlock(&g_eventlock); >> =C2=A0 =C2=A0 =C2=A0 wakeup(&g_wait_event); >> + =C2=A0 =C2=A0 mtx_unlock(&g_eventlock); >> >> too racy? It is possible, especially if something changes in scheduling >> or the wakeup() implementation, and on single-CPU machines, that the >> woken thread could run and then encounter the lock not yet released, >> leading to more lock waiting. > > As far as I have understood this is the normal way to protect against > losing wakeups, no? wakeup(9) marks the sleeping process runnable and > removes it from the sleep queue but doesn't force a context switch > immediately. Thus increased lock contention would happen only if a > context switch happens between wakeup() and mtx_unlock(). I don't see > this a problem but please correct me if I am wrong. I'm also not sure, just wanted to discuss the case. Maybe the condvar(9) API would be better here? (but that is probably out of scope for your patch, I'm just thinking aloud) From owner-freebsd-geom@FreeBSD.ORG Fri Oct 22 21:03:58 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 311901065696; Fri, 22 Oct 2010 21:03:58 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id C9A308FC1C; Fri, 22 Oct 2010 21:03:57 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 3FDD8456B1; Fri, 22 Oct 2010 23:03:56 +0200 (CEST) Received: from localhost (chello089073192049.chello.pl [89.73.192.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 5470845683; Fri, 22 Oct 2010 23:03:50 +0200 (CEST) Date: Fri, 22 Oct 2010 23:03:17 +0200 From: Pawel Jakub Dawidek To: Jaakko Heinonen Message-ID: <20101022210317.GB1742@garage.freebsd.pl> References: <4C4ED619.7050305@FreeBSD.org> <27237.1280241532@critter.freebsd.dk> <4C4F171C.9010106@FreeBSD.org> <20101021174301.GA1381@a91-153-123-205.elisa-laajakaista.fi> <20101022184645.GA1381@a91-153-123-205.elisa-laajakaista.fi> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2B/JsCI69OhZNC5r" Content-Disposition: inline In-Reply-To: <20101022184645.GA1381@a91-153-123-205.elisa-laajakaista.fi> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: Ivan Voras , freebsd-geom@freebsd.org Subject: Re: Hyperactive g_event thread X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 21:03:58 -0000 --2B/JsCI69OhZNC5r Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 22, 2010 at 09:46:46PM +0300, Jaakko Heinonen wrote: > On 2010-10-22, Ivan Voras wrote: > > Isn't this sequence: > >=20 > > - mtx_unlock(&g_eventlock); > > wakeup(&g_wait_event); > > + mtx_unlock(&g_eventlock); > >=20 > > too racy? It is possible, especially if something changes in scheduling > > or the wakeup() implementation, and on single-CPU machines, that the > > woken thread could run and then encounter the lock not yet released, > > leading to more lock waiting. >=20 > As far as I have understood this is the normal way to protect against > losing wakeups, no? You won't lose wakeup even if you unlock first and then call wakeup(), but unlocking first might save you a context switch. To avoid wakeup entirely you could remember if the tailq is empty before inserting new element and call wakeup() only if it was empty. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --2B/JsCI69OhZNC5r Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkzB/BUACgkQForvXbEpPzQe8ACgs+v2R/o/yXorY2oUoQqnercV MJ8AoNQLnBX3fhFDJO+8pU4fABsMmnwT =jpxl -----END PGP SIGNATURE----- --2B/JsCI69OhZNC5r-- From owner-freebsd-geom@FreeBSD.ORG Sat Oct 23 22:56:42 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 130501065670; Sat, 23 Oct 2010 22:56:42 +0000 (UTC) Date: Sat, 23 Oct 2010 22:56:42 +0000 From: Alexander Best To: freebsd-geom@freebsd.org Message-ID: <20101023225642.GA63520@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline Subject: improvement to 'geom class load' error output X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2010 22:56:42 -0000 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi there, this patch will improve the error output when 'geom class load' fails. right now the output for every failure is: "geom: geom_zero module not available!" with the patch geom will output the following if EPERM has been returned: "geom: Could not load module: Operation not permitted." the only "problem" with the patch is that errno is either being set by kldload(2) or modfind(2). from the output users cannot device whether kldload(2) or modfind(2) failed. with this patch the output of 'geom class load' should very much equal the one from 'geom class unload'. cheers. alex -- a13x --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="geom.c.diff" diff --git a/sbin/geom/core/geom.c b/sbin/geom/core/geom.c index 0a583ef..8321684 100644 --- a/sbin/geom/core/geom.c +++ b/sbin/geom/core/geom.c @@ -184,7 +184,8 @@ load_module(void) if (kldload(name2) < 0 || modfind(name1) < 0) { if (errno != EEXIST) { errx(EXIT_FAILURE, - "%s module not available!", name2); + "Could not load module: %s.", + strerror(errno)); } } } --2fHTh5uZTiUOsy+g--