From owner-freebsd-geom@FreeBSD.ORG Sun Apr 25 02:00:25 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 9F6201065670; Sun, 25 Apr 2010 02:00:25 +0000 (UTC) (envelope-from marcel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 774458FC12; Sun, 25 Apr 2010 02:00:25 +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 o3P20PYq013021; Sun, 25 Apr 2010 02:00:25 GMT (envelope-from marcel@freefall.freebsd.org) Received: (from marcel@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3P20OXe012951; Sun, 25 Apr 2010 02:00:24 GMT (envelope-from marcel) Date: Sun, 25 Apr 2010 02:00:24 GMT Message-Id: <201004250200.o3P20OXe012951@freefall.freebsd.org> To: bu7cher@yandex.ru, marcel@FreeBSD.org, freebsd-geom@FreeBSD.org From: marcel@FreeBSD.org Cc: Subject: Re: kern/145452: [geom] [panic] panic in geom_part_mbr when undoing destroy command 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, 25 Apr 2010 02:00:25 -0000 Synopsis: [geom] [panic] panic in geom_part_mbr when undoing destroy command State-Changed-From-To: open->patched State-Changed-By: marcel State-Changed-When: Sun Apr 25 02:00:05 UTC 2010 State-Changed-Why: A fix has been committed to head. http://www.freebsd.org/cgi/query-pr.cgi?pr=145452 From owner-freebsd-geom@FreeBSD.ORG Sun Apr 25 02:10:06 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 1B305106564A for ; Sun, 25 Apr 2010 02:10:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0B6CB8FC0C for ; Sun, 25 Apr 2010 02:10:06 +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 o3P2A5nI020222 for ; Sun, 25 Apr 2010 02:10:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3P2A5qH020221; Sun, 25 Apr 2010 02:10:05 GMT (envelope-from gnats) Date: Sun, 25 Apr 2010 02:10:05 GMT Message-Id: <201004250210.o3P2A5qH020221@freefall.freebsd.org> To: freebsd-geom@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/145452: commit references a PR X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2010 02:10:06 -0000 The following reply was made to PR kern/145452; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/145452: commit references a PR Date: Sun, 25 Apr 2010 01:57:02 +0000 (UTC) Author: marcel Date: Sun Apr 25 01:56:39 2010 New Revision: 207181 URL: http://svn.freebsd.org/changeset/base/207181 Log: Re-calculate a geometry when reprobing as well. PR: kern/145452 Reported by: "Andrey V. Elsukov" Modified: head/sys/geom/part/g_part.c Modified: head/sys/geom/part/g_part.c ============================================================================== --- head/sys/geom/part/g_part.c Sun Apr 25 01:56:31 2010 (r207180) +++ head/sys/geom/part/g_part.c Sun Apr 25 01:56:39 2010 (r207181) @@ -1166,6 +1166,15 @@ g_part_ctl_undo(struct gctl_req *req, st return (0); } table = gp->softc; + + /* + * Synthesize a disk geometry. Some partitioning schemes + * depend on it and since some file systems need it even + * when the partitition scheme doesn't, we do it here in + * scheme-independent code. + */ + pp = cp->provider; + g_part_geometry(table, cp, pp->mediasize / pp->sectorsize); } error = G_PART_READ(table, cp); _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-geom@FreeBSD.ORG Sun Apr 25 03:54:32 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 8A981106566B for ; Sun, 25 Apr 2010 03:54:32 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id 48EFC8FC0C for ; Sun, 25 Apr 2010 03:54:31 +0000 (UTC) Received: by qyk11 with SMTP id 11so13374155qyk.13 for ; Sat, 24 Apr 2010 20:54:22 -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=BlG9+2xKPzq55/jV8EPvKSfMekmchkn0Y2XCk8irf+Y=; b=AwdwNs0zFckVjkBeOajxwRam7yOCkVOp0sK3vFhxjMnAXZCqGAhroCIC8HzrCnHIDb siTdkLx/LNCTskRpVfkmYtAwzk0QKkZBIJJXhmyfJ5HXb1WnRe8dcqsk0yaedd5KNrkU e4IdbI3GhVy16iAytW8aQuO/mNB7YRXulfU4o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=bFFWq0jHhKzboULrDnlbPtCn/NKHN4peuyfwMoQOZaQ2HUJuseHkDXfb5Y0gmnThd3 qv3KcyhjRg3kj1qa2lCSYsBeNGor2dVwdYJzdwC4uxjlQyS0AQYKZeEud6cH9zIuyCpf O6InDcLVE1Au4UOv73SBFff5QdPRniNNvOnsc= MIME-Version: 1.0 Received: by 10.229.217.14 with SMTP id hk14mr2570747qcb.89.1272167662304; Sat, 24 Apr 2010 20:54:22 -0700 (PDT) Received: by 10.229.233.11 with HTTP; Sat, 24 Apr 2010 20:54:22 -0700 (PDT) Date: Sat, 24 Apr 2010 20:54:22 -0700 Message-ID: From: Garrett Cooper To: freebsd-geom@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: dumpdev must be manually set via loader(8) (potential regression?)? 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, 25 Apr 2010 03:54:32 -0000 Hi GEOM folks, I recently tried reproducing a panic on 8-STABLE, and I noticed that the following specifying dumpdev="AUTO" after the system had booted up multiuser wasn't functional. dumpon(8) kept complaining that "kernel dumps disabled" as the ioctl(2) call shortly before the printf was failing: i = ioctl(fd, DIOCSKERNELDUMP, &u); Specifying an explicit dumpdev failed as well. kenv setting the explicit dumpdev in multiuser mode failed. Booting up via the bootloader specifying dumpdev="" worked though. So I did some digging and it turns out that geom defines what swap devices are available for dumping, via g_dev_ioctl (sys/geom/geom_dev.c:273 on 8-STABLE): case DIOCSKERNELDUMP: u = *((u_int *)data); if (!u) { set_dumper(NULL); error = 0; break; } kd.offset = 0; kd.length = OFF_MAX; i = sizeof kd; error = g_io_getattr("GEOM::kerneldump", cp, &i, &kd); if (!error) dev->si_flags |= SI_DUMPDEV; break; So whatever facility sets the attribute `GEOM::kerneldump' doesn't seem to be 100% correct. I know that this functionality worked at one point in time, but the last time I've had to actually do this is ages ago (5.x or 6.x days), so I'm not sure what changed and when to cause this breakage. Finally, I tested to see whether or not it was an issue purely on 8-STABLE, and the same thing occurs on a slightly stale copy of 9-CURRENT. The machine configurations are listed below. Thanks, -Garrett The Lenovo: $ kldstat Id Refs Address Size Name 1 16 0xc0400000 833144 kernel 2 1 0xc0c34000 1c0b4 snd_hda.ko 3 2 0xc0c51000 56240 sound.ko 4 1 0xc0ca8000 a0d1f4 nvidia.ko 5 1 0xc6dad000 2000 blank_saver.ko $ uname -a FreeBSD garrcoop-fbsd.cisco.com 8.0-STABLE FreeBSD 8.0-STABLE #0 r207006: Wed Apr 21 13:18:44 PDT 2010 root@garrcoop-fbsd.cisco.com:/usr/obj/usr/src/sys/LAPPY_X86 i386 cpu I686_CPU ident LAPPY_X86 makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options INCLUDE_CONFIG_FILE options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSLOCKD # Network Lock Manager options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat (sgtty) options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options COMPAT_LINUX # Linux-ulater..... blah. # PENGUINS -- THE OTHER WHITE MEAT! options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options P1003_1B_SEMAPHORES # POSIX-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. options KBD_INSTALL_CDEV # install a CDEV entry in /dev options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing options MAC # TrustedBSD MAC Framework options FLOWTABLE # per-cpu routing cache #options KDTRACE_HOOKS # Kernel DTrace hooks # Debugger junk. options DDB options KDB # To make an SMP kernel, the next two lines are needed options SMP # Symmetric MultiProcessor Kernel device apic # I/O APIC # CPU frequency control device cpufreq # Bus support. device acpi # IBM specific hooks for ACPI. device acpi_ibm device eisa device pci # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives options ATA_STATIC_ID # Static device numbering device scbus device pass device cd device da device sa device iir device atkbdc device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device uart # Generic UART driver # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device ppi # Parallel port interface device # PCI Ethernet NICs. device em # Intel PRO/1000 Gigabit Ethernet Family # Wireless NIC cards device wlan # 802.11 support options IEEE80211_DEBUG # enable debug msgs options IEEE80211_AMPDU_AGE # age frames in AMPDU reorder q's options IEEE80211_SUPPORT_MESH # enable 802.11s draft support device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_amrr # AMRR transmit rate control algorithm # Intel wireless. device iwn device iwnfw # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device tun # Packet tunnel. device pty # BSD-style compatibility pseudo ttys device md # Memory "disks" device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse # USB Serial devices device uark # Technologies ARK3116 based serial adapters device ubsa # Belkin F5U103 and compatible serial adapters device uftdi # For FTDI usb serial adapters device uplcom # Prolific PL-2303 serial adapters device uslcom # SI Labs CP2101/CP2102 serial adapters The server: $ kldstat Id Refs Address Size Name 1 28 0xffffffff80100000 779f60 kernel 2 3 0xffffffff8087a000 4b7f0 linux.ko 3 1 0xffffffff808c6000 dbb8 if_re.ko 4 1 0xffffffff808d4000 2bad8 kqemu.ko 5 1 0xffffffff80900000 d451a0 nvidia.ko 6 1 0xffffffff81812000 4dd0 linprocfs.ko 7 1 0xffffffff81817000 2c2 blank_saver.ko $ uname -a FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r206173M: Sat Apr 17 22:42:39 PDT 2010 root@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 cpu HAMMER ident BAYONETTA makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFSLOCKD # Network Lock Manager options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_FREEBSD32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options P1003_1B_SEMAPHORES # POSIX-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. options KBD_INSTALL_CDEV # install a CDEV entry in /dev options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing # Debugging for use in -current options KDB # Enable kernel debugger support. options DDB # Support DDB. # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # CPU frequency control device cpufreq # Bus support. device acpi device pci device coretemp # Intel temperature monitoring driver. device smbus device smb device ichsmb # ATA and ATAPI devices options ATA_CAM device ahci device ataahci device atacore device ataintel device atapci # SCSI Controllers device mfi # LSI MegaRAID Firmware Interface driver. # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device cd # CD device pass # Passthrough device (direct SCSI access) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Serial (COM) ports device uart # Generic UART driver # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device tun # Packet tunnel. device pty # BSD-style compatibility pseudo ttys device md # Memory "disks" # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) device uhid # "Human Interface Devices" device ukbd # Keyboard device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse # FireWire support device firewire # FireWire bus code device sbp # SCSI over FireWire (Requires scbus and da) device sound device snd_emu10kx From owner-freebsd-geom@FreeBSD.ORG Sun Apr 25 09:46:50 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 38C981065670 for ; Sun, 25 Apr 2010 09:46:50 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nskntqsrv02p.mx.bigpond.com (nskntqsrv02p.mx.bigpond.com [61.9.168.234]) by mx1.freebsd.org (Postfix) with ESMTP id 9BEB08FC22 for ; Sun, 25 Apr 2010 09:46:49 +0000 (UTC) Received: from nskntotgx01p.mx.bigpond.com ([124.188.161.100]) by nskntmtas02p.mx.bigpond.com with ESMTP id <20100425080125.JLNK4632.nskntmtas02p.mx.bigpond.com@nskntotgx01p.mx.bigpond.com>; Sun, 25 Apr 2010 08:01:25 +0000 Received: from duncan.reilly.home ([124.188.161.100]) by nskntotgx01p.mx.bigpond.com with ESMTP id <20100425080125.FQUN1945.nskntotgx01p.mx.bigpond.com@duncan.reilly.home>; Sun, 25 Apr 2010 08:01:25 +0000 Date: Sun, 25 Apr 2010 18:01:25 +1000 From: Andrew Reilly To: Marius Strobl Message-ID: <20100425080125.GA12283@duncan.reilly.home> References: <4BD06BD9.6030401@FreeBSD.org> <20100424193034.GA9853@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100424193034.GA9853@alchemy.franken.de> User-Agent: Mutt/1.4.2.3i X-Authentication-Info: Submitted using SMTP AUTH LOGIN at nskntotgx01p.mx.bigpond.com from [124.188.161.100] using ID areilly@bigpond.net.au at Sun, 25 Apr 2010 08:01:25 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150203.4BD3F6D5.00BD,ss=1,fgs=0 X-SIH-MSG-ID: rBEzFdb2TAD0zmQs0WyzOwJxyArnqyN48Z4QX81loRIGTUDCp8DeQ9rANv1RsM6kxDxJJhqNNGEhaa7hTY3Rs9mK Cc: Alexander Motin , FreeBSD-Current , freebsd-geom@freebsd.org Subject: usb/da vs sata geometry calculations (was Re: Switchover to CAM ATA?) 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, 25 Apr 2010 09:46:50 -0000 Hi all, Sorry to interrupt this thread with an off-topic question, but it seems vaguely related, and you folk seem to be the right ones to ask: I've recently done a drive upgrade in a 1U rack machine that only had space for the two active drives that were in it, and I couldn't afford the down-time that it would take to install from scratch. So I formatted and populated the first replacement drive in an external USB cradle, and when it was looking like a good replacement for the (gmirror'd) image that was running, I did the physical swap, and all was good, as expected. All except that that the identical drive that I inserted as the second element of the mirror would *not* accept a copy of the first disk's MBR block (with fdisk). It said that the calculated geometry was incompatible. Luckily for me (I think) the calculated geometry was a megabyte or so *larger* than the first drive, so I was still able to bsdlabel it to match, and slot it into the gmirror as planned. Was this the result of the umass/da driver having a different synthetic geometry calculation routine than the SATA driver? This was all on an 8-STABLE system about 400 days old, fwiw. Should I expect any on-going badness as a result of this difference in "geometry" between two identical drives? Cheers, -- Andrew From owner-freebsd-geom@FreeBSD.ORG Mon Apr 26 10:53:18 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 93CF210656AE for ; Mon, 26 Apr 2010 10:53:18 +0000 (UTC) (envelope-from lister@kawashti.org) Received: from mra.kawashti.org (mra.kawashti.org [78.136.5.95]) by mx1.freebsd.org (Postfix) with ESMTP id 31D3C8FC1A for ; Mon, 26 Apr 2010 10:53:17 +0000 (UTC) Received: from mx.kawashti.org (mx.kawashti.org [196.218.21.179]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mra.kawashti.org (Postfix) with ESMTP id B82CA47C153 for ; Mon, 26 Apr 2010 11:53:15 +0100 (BST) Received: from neo ([10.10.10.10]) by mx.kawashti.org (Kawashti Mail) with SMTP id RDS02182 for ; Mon, 26 Apr 2010 12:53:14 +0200 Message-ID: <2ADD2F3170654D21818307E326F42E83@neo> From: "Lister" To: "GEOM" Date: Mon, 26 Apr 2010 12:53:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1256"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4548 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Subject: Re: OCE and GPT. No Dice! 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, 26 Apr 2010 10:53:18 -0000 No Dice! That's the result of my experiment which I promised to share with you. Short version: ============== growfs is just as limited as fdisk and bsdlabel, and apparently dumpfs. $ growfs /dev/da0p2 growfs: we are not growing (50384895->32089087) growfs believes the partition is to be shrunk from 50 (24GB) million sectors to 32, rather than for 6.4 billion (3,075GB) to 8.4 (4,006GB)! Any ideas? Other tools? Are there any other FS which are known to be stable under FreeBSD and for which there are tools to live-convert a UFS to them? Too far fetched, ay? Long version: it might be interesting: =========================== To circumvert the 3dm2 not working under 8.0-REL, I disconnected the 2 drives comprising the RAID1 from which the system boots, got a 120GB ATA from junk, installed 7.1 on it and subsequently 3dm2. Although this wasn't necessary, I unmounted the 2 FS on /dev/da0 before OCE, and also made them noauto in /etc/fstab. I did the OCE. It took 47 hours to complete. Those were in 3 stages: Migration took 34-35:30, Initialization took 7:45-9:15 and Verification took 3:45 hours. Contrary to 3ware's documentation, I found that removing the unit and rescanning after OCE has completed were unnecessary. Some how, FreeBSD had already been notified of the changed disk size. Evidence: $ diskinfo -v /dev/da0 /dev/da0 512 # sectorsize 4999945912320 # mediasize in bytes (4.5T) 9765519360 # mediasize in sectors 607875 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. 9QJ2LCKPA2632A007413 # Disk ident. Next I used gpart to delete the 2 partitions and destroy the GPT. Subsequently I created p1 of the same size as the old one and p2 for all the remaining space. Here's the output after having done so: $ gpart show da0 => 34 9765519293 da0 GPT (4.5T) 34 1363148800 1 freebsd-ufs (650G) 1363148834 8402370493 2 freebsd-ufs (3.9T) BTW, I incidentally learned that gpart on 7.1 is different from 8.0. Unlike the latter, the former insists to have -b option. Also it insists to have -s option even if the partition was the last one. On 8.0, I would just use -i and no -b, and no -s for the last partition which defaults to using all the remaining space. So, I'll have to modify my script– which I wrote for and tested only on 8.0– to include partition math. One can't make any assumption about anything! Then I tried the growfs command as in "Short version." Given the unfavorable output, I thought may be I should still remove the unit from 3dm2 and rescan afterall. I did that and repeated the growfs, only to get the same result. I thought, let's just reboot. Did and retried growfs, again for the same. Then I thought, may be growfs had been imporved on 8.0-REL; afterall, I no longer need 7.1 now that OCE had been done. I booted from 8.0 and tried once more, but to no avail. Before I did the migration, I saved outputs of dumpfs -m, gpart show and tunefs -p for reference. $ gpart show da0 => 34 7812415421 da0 GPT (3.6T) 34 1363148800 1 freebsd-ufs (650G) 1363148834 6449266621 2 freebsd-ufs (3.0T) $ dumpfs -m /dev/da0p2 newfs -O 2 -U -a 2 -b 65536 -d 65536 -e 8192 -f 65536 -g 16384 -h 64 -m 8 -o time -s 50384895 /dev/da0p2 I didn't pay attention to this output, then. It turned out to be exactly the same after expansion. I couldn't work out where the figure 50384895 came from, though. It is not sectors % 2^32, for example. I've read that fdisk and bsdlabel have a limit of (2^32 -1) sectors. Neither could I find any logic that would make it the same before and after expansion. Note, however that dumpfs and growfs differ in the size after expansion. While dumpfs maintained the same number, growfs got a smaller number after expansion. I hope someone would care to comment on that. --- Hatem Kawashti From owner-freebsd-geom@FreeBSD.ORG Mon Apr 26 11:07:01 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 66D19106566B for ; Mon, 26 Apr 2010 11:07:01 +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 551CD8FC21 for ; Mon, 26 Apr 2010 11:07:01 +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 o3QB712u004159 for ; Mon, 26 Apr 2010 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3QB7095004157 for freebsd-geom@FreeBSD.org; Mon, 26 Apr 2010 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 26 Apr 2010 11:07:00 GMT Message-Id: <201004261107.o3QB7095004157@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, 26 Apr 2010 11:07:01 -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 kern/145818 geom [geom] geom_stat_open showing cached information for n p kern/145452 geom [geom] [panic] panic in geom_part_mbr when undoing des 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 bin/144943 geom [geom] gconcat(8) randomly "loses" all knowledge of JB o kern/144905 geom [geom][gpart] panic in gpart_ctlreq when unplugging ca o kern/144732 geom [geom] [patch] geom_cache erroneously decodes its on-d o bin/144521 geom geom(1) tool parsing non-subclass command broken 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 o kern/140352 geom [geom] gjournal + glabel not working o kern/139847 geom [geom_mbr] [patch] load/unload causes system to hang 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/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 56 problems total. From owner-freebsd-geom@FreeBSD.ORG Mon Apr 26 12:51:21 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 3BE80106564A; Mon, 26 Apr 2010 12:51:21 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id 95B088FC0A; Mon, 26 Apr 2010 12:51:20 +0000 (UTC) Received: by ewy24 with SMTP id 24so3405787ewy.33 for ; Mon, 26 Apr 2010 05:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=Pnnr3KtMJEqenHrrQr3cArJah/TlZ0SkTkpzdfp6wWo=; b=FVHCrkR60fxhnIFwwZaHRxfG6mTt5QAhuZTWMDR2ngfCNOo3rH4X1tjlVkZnfq6ubX ahPLMZUwyPzfv8ZFpB53WRgQZv3jPrtixjC5CW+GPWbefR6sTo5hS98kjVxgZrDv3IdE HS8aDBOIZkoxkgg55tOgOfxakbknUfih8T2W4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=MNsos9322zVxi/xZQDbm76lHFv7cCu4KS50yjtmcbK+hdiPm0WyGvEujBVhLGDvI7v Y7zNIsMmTGDVyLUnb5YYlEXUdusPilp3KaAWgbDKcVF6FYg0ZrnOYojO7gBhsVZpPNca Z1PYagx1pkfbmEwLmww3D1wRtJfvmvH4EQ24E= Received: by 10.102.16.36 with SMTP id 36mr2220042mup.124.1272286276496; Mon, 26 Apr 2010 05:51:16 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id y2sm16181453mug.21.2010.04.26.05.51.14 (version=SSLv3 cipher=RC4-MD5); Mon, 26 Apr 2010 05:51:15 -0700 (PDT) Sender: Alexander Motin Message-ID: <4BD58C35.2010305@FreeBSD.org> Date: Mon, 26 Apr 2010 15:51:01 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Marius Strobl References: <4BD06BD9.6030401@FreeBSD.org> <20100424193034.GA9853@alchemy.franken.de> In-Reply-To: <20100424193034.GA9853@alchemy.franken.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , freebsd-geom@freebsd.org Subject: Re: Switchover to CAM ATA? 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, 26 Apr 2010 12:51:21 -0000 Marius Strobl wrote: > As noted earlier, pc98 and sparc64 need ada(4)/CAM ATA to perform > geometry translation as done by ad_firmware_geom_adjust() for ad(4), > which the following patch hooks up to both: > http://people.freebsd.org/~marius/ata_disk_firmware_geom_adjust.diff > You preferred to implement such functionality via XPT_CALC_GEOMETRY > though (I'm still not convinced that it makes sense to put this > functionality into every ATA SIM the same way it is done for SCSI > rather than letting ada(4) handle it the same way for all SIMs > however). Have you looked into implementing XPT_CALC_GEOMETRY for > ATA CAM or is it okay to commit the above patch? Sorry, I have forgotten about this. I don't have better idea. For ATA translation seems indeed more platform- then controller-specific. May be I would just preferred to see this hack to be done inside XPT_CALC_GEOMETRY handler, as it is done now for PC98 SCSI. But looking that whole this topic is quite crappy and hopefully going to die sometimes, I won't argue much against committing this as-is for now. -- Alexander Motin From owner-freebsd-geom@FreeBSD.ORG Mon Apr 26 12:56:16 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 53FCA106566B for ; Mon, 26 Apr 2010 12:56:16 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9DF0B8FC14 for ; Mon, 26 Apr 2010 12:56:15 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA02790; Mon, 26 Apr 2010 15:56:09 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4BD58D69.1030308@icyb.net.ua> Date: Mon, 26 Apr 2010 15:56:09 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: Lister References: <2ADD2F3170654D21818307E326F42E83@neo> In-Reply-To: <2ADD2F3170654D21818307E326F42E83@neo> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=windows-1256 Content-Transfer-Encoding: 8bit Cc: GEOM Subject: Re: OCE and GPT. No Dice! 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, 26 Apr 2010 12:56:16 -0000 on 26/04/2010 13:53 Lister said the following: > No Dice! That's the result of my experiment which I promised to share > with you. > > Short version: > ============== > growfs is just as limited as fdisk and bsdlabel, and apparently dumpfs. > $ growfs /dev/da0p2 > growfs: we are not growing (50384895->32089087) > > growfs believes the partition is to be shrunk from 50 (24GB) million > sectors to 32, rather than for 6.4 billion (3,075GB) to 8.4 (4,006GB)! Wrong, see below. > Any ideas? Other tools? Fix growisofs :) Something to try before that - use explicit -s option. > Are there any other FS which are known to be stable under FreeBSD and > for which there are tools to live-convert a UFS to them? Too far > fetched, ay? > > Long version: it might be interesting: > =========================== > To circumvert the 3dm2 not working under 8.0-REL, I disconnected the 2 > drives comprising the RAID1 from which the system boots, got a 120GB ATA > from junk, installed 7.1 on it and subsequently 3dm2. > > Although this wasn't necessary, I unmounted the 2 FS on /dev/da0 before > OCE, and also made them noauto in /etc/fstab. > > I did the OCE. It took 47 hours to complete. Those were in 3 stages: > Migration took 34-35:30, Initialization took 7:45-9:15 and Verification > took 3:45 hours. > > Contrary to 3ware's documentation, I found that removing the unit and > rescanning after OCE has completed were unnecessary. Some how, FreeBSD > had already been notified of the changed disk size. Evidence: > $ diskinfo -v /dev/da0 > /dev/da0 > 512 # sectorsize > 4999945912320 # mediasize in bytes (4.5T) > 9765519360 # mediasize in sectors > 607875 # Cylinders according to firmware. > 255 # Heads according to firmware. > 63 # Sectors according to firmware. > 9QJ2LCKPA2632A007413 # Disk ident. > > Next I used gpart to delete the 2 partitions and destroy the GPT. > Subsequently I created p1 of the same size as the old one and p2 for all > the remaining space. Here's the output after having done so: > $ gpart show da0 > => 34 9765519293 da0 GPT (4.5T) > 34 1363148800 1 freebsd-ufs (650G) > 1363148834 8402370493 2 freebsd-ufs (3.9T) > > BTW, I incidentally learned that gpart on 7.1 is different from 8.0. > Unlike the latter, the former insists to have -b option. Also it insists > to have -s option even if the partition was the last one. On 8.0, I > would just use -i and no -b, and no -s for the last partition which > defaults to using all the remaining space. So, I'll have to modify my > script– which I wrote for and tested only on 8.0– to include partition > math. One can't make any assumption about anything! > > Then I tried the growfs command as in "Short version." Given the > unfavorable output, I thought may be I should still remove the unit from > 3dm2 and rescan afterall. I did that and repeated the growfs, only to > get the same result. I thought, let's just reboot. Did and retried > growfs, again for the same. > Then I thought, may be growfs had been imporved on 8.0-REL; afterall, I > no longer need 7.1 now that OCE had been done. I booted from 8.0 and > tried once more, but to no avail. > > Before I did the migration, I saved outputs of dumpfs -m, gpart show and > tunefs -p for reference. > $ gpart show da0 > => 34 7812415421 da0 GPT (3.6T) > 34 1363148800 1 freebsd-ufs (650G) > 1363148834 6449266621 2 freebsd-ufs (3.0T) > > $ dumpfs -m /dev/da0p2 > newfs -O 2 -U -a 2 -b 65536 -d 65536 -e 8192 -f 65536 -g 16384 -h 64 -m > 8 -o time -s 50384895 /dev/da0p2 > I didn't pay attention to this output, then. It turned out to be exactly > the same after expansion. I couldn't work out where the figure 50384895 > came from, though. It is not sectors % 2^32, for example. I've read that > fdisk and bsdlabel have a limit of (2^32 -1) sectors. Neither could I > find any logic that would make it the same before and after expansion. 50384895 is number of filesystem blocks in the filesystem. filesystem block size is 64K in your case, see 'newfs ...' line above. What logic did you find to think that it should not be the same? > Note, however that dumpfs and growfs differ in the size after expansion. > While dumpfs maintained the same number, growfs got a smaller number > after expansion. Your filesystem has not changed, so why would dumpfs report anything different? > I hope someone would care to comment on that. -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Mon Apr 26 13:07:56 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 E12941065670; Mon, 26 Apr 2010 13:07:56 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id 42A728FC1F; Mon, 26 Apr 2010 13:07:55 +0000 (UTC) Received: by ewy24 with SMTP id 24so3417040ewy.33 for ; Mon, 26 Apr 2010 06:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=3taVqRM+buewQXXUtEz8GyVSZa07awlY3KfEcxkaEzE=; b=ajf1d3QvddD6HJKfD7cCTfFRxyVc0d+bbv4wUu2Rb6EmM6/k3285NTnyR+ppw4rg9e QJREn/dty20LYzmWTGHqIPUNvHBeu9VeL0aPTS154ec9vqK2UGEKaLyvY/GyodxnyagR ISHxZQFQISEEXgm44UnBz4QtiX+Ue5Y0BxxQk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=FvHBMF2gf9T5m6Sabnb+rEOom/xlfrhbG+C/Wb77qaAGnkw4dY2LH2fYwHQ0n+x1/w gnA5Hl7OdMb5cmotlXG2HjiPo+BdoUU1bslDy+vBGd/FTnoygmMbARpc0F69qeDHMkh4 EtD2Ptjr2m2OVuYqVQOKTXrqzwLWhRhYGG8fM= Received: by 10.103.48.21 with SMTP id a21mr2241433muk.98.1272287270308; Mon, 26 Apr 2010 06:07:50 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id j2sm16958160mue.23.2010.04.26.06.07.48 (version=SSLv3 cipher=RC4-MD5); Mon, 26 Apr 2010 06:07:49 -0700 (PDT) Sender: Alexander Motin Message-ID: <4BD59018.40805@FreeBSD.org> Date: Mon, 26 Apr 2010 16:07:36 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Andrew Reilly References: <4BD06BD9.6030401@FreeBSD.org> <20100424193034.GA9853@alchemy.franken.de> <20100425080125.GA12283@duncan.reilly.home> In-Reply-To: <20100425080125.GA12283@duncan.reilly.home> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-geom@freebsd.org, FreeBSD-Current , Marius Strobl Subject: Re: usb/da vs sata geometry calculations (was Re: Switchover to CAM ATA?) 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, 26 Apr 2010 13:07:57 -0000 Andrew Reilly wrote: > Was this the result of the umass/da driver having a different > synthetic geometry calculation routine than the SATA driver? ATA and SCSI disk drivers indeed have different geometry calculation algorithms. ATA fetches geometry from DEVICE IDENTIFY data, while SCSI seems just fakes them in many cases. > This was all on an 8-STABLE system about 400 days old, fwiw. > > Should I expect any on-going badness as a result of this > difference in "geometry" between two identical drives? I hope not. LBA-aware loaders should use LBA offsets of the partitions, which are not depending on geometry. -- Alexander Motin From owner-freebsd-geom@FreeBSD.ORG Mon Apr 26 13:32:08 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 826C9106566B for ; Mon, 26 Apr 2010 13:32:08 +0000 (UTC) (envelope-from lister@kawashti.org) Received: from mra.kawashti.org (mra.kawashti.org [78.136.5.95]) by mx1.freebsd.org (Postfix) with ESMTP id 2087F8FC0A for ; Mon, 26 Apr 2010 13:32:07 +0000 (UTC) Received: from mx.kawashti.org (mx.kawashti.org [196.218.21.179]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mra.kawashti.org (Postfix) with ESMTP id 683584902E4 for ; Mon, 26 Apr 2010 14:32:06 +0100 (BST) Received: from neo ([10.10.10.10]) by mx.kawashti.org (Kawashti Mail) with SMTP id RDS02182 for ; Mon, 26 Apr 2010 15:32:05 +0200 Message-ID: From: "Lister" To: "GEOM" Date: Mon, 26 Apr 2010 15:32:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1256"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4548 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Subject: Re: OCE and GPT. No Dice! 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, 26 Apr 2010 13:32:08 -0000 I didn't think 50384895 was in blocks because growfs itself takes -s for input and it's man page has nothing about errors in blocks, or at all! Again, according to dumpfs manpage, and I quote "If -m is specified, a newfs(8) command is printed that can be used to generate a new file system with equivalent settings." newfs takes -s not blocks. Given that, dumpfs has a bug, at least with -m option. Regarding explicit -s with growfs, I did try that (in sectors), and just forgot to mention it. growisofs: I'll look into it shortly; thank you. --- Hatem Kawashti ----- Original Message ----- From: "Andriy Gapon" To: "Lister" Cc: "GEOM" Sent: Monday, April 26, 2010 14:56 Subject: Re: OCE and GPT. No Dice! > on 26/04/2010 13:53 Lister said the following: >> No Dice! That's the result of my experiment which I promised to share >> with you. >> >> Short version: >> ============== >> growfs is just as limited as fdisk and bsdlabel, and apparently dumpfs. >> $ growfs /dev/da0p2 >> growfs: we are not growing (50384895->32089087) >> >> growfs believes the partition is to be shrunk from 50 (24GB) million >> sectors to 32, rather than for 6.4 billion (3,075GB) to 8.4 (4,006GB)! > > Wrong, see below. > >> Any ideas? Other tools? > > Fix growisofs :) > Something to try before that - use explicit -s option. > >> Are there any other FS which are known to be stable under FreeBSD and >> for which there are tools to live-convert a UFS to them? Too far >> fetched, ay? >> >> Long version: it might be interesting: >> =========================== >> To circumvert the 3dm2 not working under 8.0-REL, I disconnected the 2 >> drives comprising the RAID1 from which the system boots, got a 120GB ATA >> from junk, installed 7.1 on it and subsequently 3dm2. >> >> Although this wasn't necessary, I unmounted the 2 FS on /dev/da0 before >> OCE, and also made them noauto in /etc/fstab. >> >> I did the OCE. It took 47 hours to complete. Those were in 3 stages: >> Migration took 34-35:30, Initialization took 7:45-9:15 and Verification >> took 3:45 hours. >> >> Contrary to 3ware's documentation, I found that removing the unit and >> rescanning after OCE has completed were unnecessary. Some how, FreeBSD >> had already been notified of the changed disk size. Evidence: >> $ diskinfo -v /dev/da0 >> /dev/da0 >> 512 # sectorsize >> 4999945912320 # mediasize in bytes (4.5T) >> 9765519360 # mediasize in sectors >> 607875 # Cylinders according to firmware. >> 255 # Heads according to firmware. >> 63 # Sectors according to firmware. >> 9QJ2LCKPA2632A007413 # Disk ident. >> >> Next I used gpart to delete the 2 partitions and destroy the GPT. >> Subsequently I created p1 of the same size as the old one and p2 for all >> the remaining space. Here's the output after having done so: >> $ gpart show da0 >> => 34 9765519293 da0 GPT (4.5T) >> 34 1363148800 1 freebsd-ufs (650G) >> 1363148834 8402370493 2 freebsd-ufs (3.9T) >> >> BTW, I incidentally learned that gpart on 7.1 is different from 8.0. >> Unlike the latter, the former insists to have -b option. Also it insists >> to have -s option even if the partition was the last one. On 8.0, I >> would just use -i and no -b, and no -s for the last partition which >> defaults to using all the remaining space. So, I'll have to modify my >> script– which I wrote for and tested only on 8.0– to include partition >> math. One can't make any assumption about anything! >> >> Then I tried the growfs command as in "Short version." Given the >> unfavorable output, I thought may be I should still remove the unit from >> 3dm2 and rescan afterall. I did that and repeated the growfs, only to >> get the same result. I thought, let's just reboot. Did and retried >> growfs, again for the same. >> Then I thought, may be growfs had been imporved on 8.0-REL; afterall, I >> no longer need 7.1 now that OCE had been done. I booted from 8.0 and >> tried once more, but to no avail. >> >> Before I did the migration, I saved outputs of dumpfs -m, gpart show and >> tunefs -p for reference. >> $ gpart show da0 >> => 34 7812415421 da0 GPT (3.6T) >> 34 1363148800 1 freebsd-ufs (650G) >> 1363148834 6449266621 2 freebsd-ufs (3.0T) >> >> $ dumpfs -m /dev/da0p2 >> newfs -O 2 -U -a 2 -b 65536 -d 65536 -e 8192 -f 65536 -g 16384 -h 64 -m >> 8 -o time -s 50384895 /dev/da0p2 >> I didn't pay attention to this output, then. It turned out to be exactly >> the same after expansion. I couldn't work out where the figure 50384895 >> came from, though. It is not sectors % 2^32, for example. I've read that >> fdisk and bsdlabel have a limit of (2^32 -1) sectors. Neither could I >> find any logic that would make it the same before and after expansion. > > 50384895 is number of filesystem blocks in the filesystem. > filesystem block size is 64K in your case, see 'newfs ...' line above. > > What logic did you find to think that it should not be the same? > >> Note, however that dumpfs and growfs differ in the size after expansion. >> While dumpfs maintained the same number, growfs got a smaller number >> after expansion. > > Your filesystem has not changed, so why would dumpfs report anything different? > >> I hope someone would care to comment on that. > > -- > Andriy Gapon > _______________________________________________ > freebsd-geom@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-geom > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" From owner-freebsd-geom@FreeBSD.ORG Mon Apr 26 13:58:23 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 C0C41106564A for ; Mon, 26 Apr 2010 13:58:23 +0000 (UTC) (envelope-from lister@kawashti.org) Received: from mra.kawashti.org (mra.kawashti.org [78.136.5.95]) by mx1.freebsd.org (Postfix) with ESMTP id 5DAD28FC0C for ; Mon, 26 Apr 2010 13:58:23 +0000 (UTC) Received: from mx.kawashti.org (mx.kawashti.org [196.218.21.179]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mra.kawashti.org (Postfix) with ESMTP id 74C004902E4; Mon, 26 Apr 2010 14:58:21 +0100 (BST) Received: from neo ([10.10.10.10]) by mx.kawashti.org (Kawashti Mail) with SMTP id RDS02182; Mon, 26 Apr 2010 15:58:20 +0200 Message-ID: <8918FD47C14E4E15B944767526733C02@neo> From: "Lister" To: "Andriy Gapon" References: <2ADD2F3170654D21818307E326F42E83@neo> <4BD58D69.1030308@icyb.net.ua> <31480C3D06384DB581253007A52C6F61@neo> <4BD5966C.1030903@icyb.net.ua> <4BD59A21.9070509@icyb.net.ua> Date: Mon, 26 Apr 2010 15:58:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1256"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4548 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Cc: GEOM Subject: Re: OCE and GPT. No Dice! 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, 26 Apr 2010 13:58:23 -0000 $ dumpfs /dev/da0p2 magic 19540119 (UFS2) time Sun Apr 25 20:40:18 2010 superblock location 65536 id [ 4bd08383 b5a1e1a4 ] ncg 205 size 50384895 blocks 50359677 bsize 65536 shift 16 mask 0xffff0000 fsize 65536 shift 16 mask 0xffff0000 frag 1 shift 0 fsbtodb 7 minfree 8% optim time symlinklen 120 maxbsize 65536 maxbpg 8192 maxcontig 2 contigsumsize 2 nbfree 49949427 ndir 5 nifree 6350052 nffree 0 bpg 245897 fpg 245897 ipg 30976 unrefs 0 nindir 8192 inopb 256 maxfilesize 36033195603132415 sbsize 8192 cgsize 65536 csaddr 125 cssize 65536 sblkno 2 cblkno 3 iblkno 4 dblkno 125 cgrotor 57 fmod 0 ronly 0 clean 1 avgfpdir 64 avgfilesize 16384 flags soft-updates fsmnt /SH/huge volname swuid 0 I'd also like to suggest growfs be in a bug state for the same reason as dumpfs. It reports its error in blocks while it takes input in sectors. ----- Hatem Kawashti ----- Original Message ----- From: "Andriy Gapon" To: "Lister" Sent: Monday, April 26, 2010 15:50 Subject: !Probable-UBE! Re: OCE and GPT. No Dice! > on 26/04/2010 16:34 Andriy Gapon said the following: >> on 26/04/2010 16:31 Lister said the following: >>> I didn't think 50384895 was in blocks because growfs itself takes -s >>> for input and it's man page has nothing about errors in >>> blocks, or at all! >>> Again, according to dumpfs manpage, and I quote "If -m is specified, a >>> newfs(8) command is printed that can be used to generate a new file >>> system with equivalent settings." newfs takes -s not blocks. >>> Given that, dumpfs has a bug, at least with -m option. >> >> Yep, I agree, it's a mess. > > In fact, it's quite strange. > Can you provide output of dumpfs without -m option, only the header (before first > blank line)? > > > -- > Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Mon Apr 26 15:09:25 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 A1B621065673 for ; Mon, 26 Apr 2010 15:09:25 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E67E78FC1D for ; Mon, 26 Apr 2010 15:09:24 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA06122; Mon, 26 Apr 2010 18:09:20 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4BD5ACA0.8000907@icyb.net.ua> Date: Mon, 26 Apr 2010 18:09:20 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: Lister References: <2ADD2F3170654D21818307E326F42E83@neo> <4BD58D69.1030308@icyb.net.ua> <31480C3D06384DB581253007A52C6F61@neo> <4BD5966C.1030903@icyb.net.ua> <4BD59A21.9070509@icyb.net.ua> <8918FD47C14E4E15B944767526733C02@neo> In-Reply-To: <8918FD47C14E4E15B944767526733C02@neo> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=windows-1256 Content-Transfer-Encoding: 7bit Cc: GEOM Subject: Re: OCE and GPT. No Dice! 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, 26 Apr 2010 15:09:25 -0000 on 26/04/2010 16:58 Lister said the following: > $ dumpfs /dev/da0p2 > magic 19540119 (UFS2) time Sun Apr 25 20:40:18 2010 > superblock location 65536 id [ 4bd08383 b5a1e1a4 ] > ncg 205 size 50384895 blocks 50359677 > bsize 65536 shift 16 mask 0xffff0000 > fsize 65536 shift 16 mask 0xffff0000 > frag 1 shift 0 fsbtodb 7 > minfree 8% optim time symlinklen 120 > maxbsize 65536 maxbpg 8192 maxcontig 2 contigsumsize 2 > nbfree 49949427 ndir 5 nifree 6350052 nffree 0 > bpg 245897 fpg 245897 ipg 30976 unrefs 0 > nindir 8192 inopb 256 maxfilesize 36033195603132415 > sbsize 8192 cgsize 65536 csaddr 125 cssize 65536 > sblkno 2 cblkno 3 iblkno 4 dblkno 125 > cgrotor 57 fmod 0 ronly 0 clean 1 > avgfpdir 64 avgfilesize 16384 > flags soft-updates > fsmnt /SH/huge > volname swuid 0 > > I'd also like to suggest growfs be in a bug state for the same reason as > dumpfs. It reports its error in blocks while it takes input in sectors. OK, it seems that tunefs -m output has already been fixed in r198231 on Feb 9. This has already been MFC-ed to stable/8, not sure about stable/7. > ----- > Hatem Kawashti > ----- Original Message ----- From: "Andriy Gapon" > To: "Lister" > Sent: Monday, April 26, 2010 15:50 > Subject: !Probable-UBE! Re: OCE and GPT. No Dice! > > >> on 26/04/2010 16:34 Andriy Gapon said the following: >>> on 26/04/2010 16:31 Lister said the following: >>>> I didn't think 50384895 was in blocks because growfs itself takes -s >>>> for input and it's man page has nothing about errors in >>>> blocks, or at all! >>>> Again, according to dumpfs manpage, and I quote "If -m is specified, a >>>> newfs(8) command is printed that can be used to generate a new file >>>> system with equivalent settings." newfs takes -s not blocks. >>>> Given that, dumpfs has a bug, at least with -m option. >>> >>> Yep, I agree, it's a mess. >> >> In fact, it's quite strange. >> Can you provide output of dumpfs without -m option, only the header >> (before first >> blank line)? >> >> >> -- >> Andriy Gapon -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Mon Apr 26 15:18:14 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 5FC611065676; Mon, 26 Apr 2010 15:18:14 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 1B8D88FC13; Mon, 26 Apr 2010 15:18:13 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.3/8.14.3) with ESMTP id o3QFI7kJ098383; Mon, 26 Apr 2010 09:18:07 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <4BD58C35.2010305@FreeBSD.org> Date: Mon, 26 Apr 2010 09:18:07 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <5446E60D-0EE8-403E-A409-071ECE2EC534@samsco.org> References: <4BD06BD9.6030401@FreeBSD.org> <20100424193034.GA9853@alchemy.franken.de> <4BD58C35.2010305@FreeBSD.org> To: Alexander Motin X-Mailer: Apple Mail (2.1078) X-Spam-Status: No, score=-1.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: freebsd-geom@freebsd.org, FreeBSD-Current , Marius Strobl Subject: Re: Switchover to CAM ATA? 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, 26 Apr 2010 15:18:14 -0000 On Apr 26, 2010, at 6:51 AM, Alexander Motin wrote: > Marius Strobl wrote: >> As noted earlier, pc98 and sparc64 need ada(4)/CAM ATA to perform >> geometry translation as done by ad_firmware_geom_adjust() for ad(4), >> which the following patch hooks up to both: >> http://people.freebsd.org/~marius/ata_disk_firmware_geom_adjust.diff >> You preferred to implement such functionality via XPT_CALC_GEOMETRY >> though (I'm still not convinced that it makes sense to put this >> functionality into every ATA SIM the same way it is done for SCSI >> rather than letting ada(4) handle it the same way for all SIMs >> however). Have you looked into implementing XPT_CALC_GEOMETRY for >> ATA CAM or is it okay to commit the above patch? >=20 > Sorry, I have forgotten about this. >=20 > I don't have better idea. For ATA translation seems indeed more > platform- then controller-specific. May be I would just preferred to = see > this hack to be done inside XPT_CALC_GEOMETRY handler, as it is done = now > for PC98 SCSI. But looking that whole this topic is quite crappy and > hopefully going to die sometimes, I won't argue much against = committing > this as-is for now. Put this into XPT_CALC_GEOMETRY. There's no point in perpetuating the = mistakes of the ata driver. Give me a day or two to think of a reasonable way to do it right. Scott From owner-freebsd-geom@FreeBSD.ORG Mon Apr 26 16:41:44 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 2D4A61065675; Mon, 26 Apr 2010 16:41:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id E1F438FC13; Mon, 26 Apr 2010 16:41:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o3QGXGAG058943; Mon, 26 Apr 2010 10:33:16 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 26 Apr 2010 10:33:27 -0600 (MDT) Message-Id: <20100426.103327.319083499807534535.imp@bsdimp.com> To: mav@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <4BD06BD9.6030401@FreeBSD.org> References: <4BD06BD9.6030401@FreeBSD.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? 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, 26 Apr 2010 16:41:44 -0000 I've read most of this thread. I think this is cool technology. However, before we move forward with this, we need to have a plan for the various issues that have come up. The plan needs to be specific, have owners for key items, warnings about ownerless == obsoleted, and target dates. I think this is one of the cases where we should record the plan of record on a wiki. It worked well for other times we've had big, disruptive changes. My opinion for the path forward: (1) Send a big heads up about the future of ataraid(5). It will be shot in the head soon, to be replaced be a bunch of geom classes for each different container format. At least that seems to be the rough consensus I've seen so far. We need worker bees to do many of these classes, although much can be mined from the ataraid code today. (2) Send another big heads up strongly recommending people go to glabel based fstabs. Maybe the right option here is to provide a simple script walk people through the conversion. This will render the carnage of ad -> ada (or da) a mostly non-event, and also protect people from 'oops' of rebooting with that thumb drive in the system. (3) Create a wiki to record all the new geom classes needed. Find people to own each one, or note it is unowned, and support will be dropped if no owner can be found. (4) sysinstall should default to creating label systems, if it doesn't already. (5) Issues with glabel and ataraid(5) need an owner, and need to be resolved, since the device names here are likely to change. (6) Someone needs to write-up a detailed description of how to do this for UPDATING. Maybe we can reuse text from #2. (7) We need a target time line for these things to happen. We can't just break ataraid(5) by default with little or no warning. Realistically, this will be for 9.0 and later systems, so we have some time before the branch to give warning, as well as pull the switch and have adequate testing time. (8) Fill in all the parts that I've missed :) Comments? Warner From owner-freebsd-geom@FreeBSD.ORG Mon Apr 26 18:12:18 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 C79CC1065674; Mon, 26 Apr 2010 18:12:18 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id E32A08FC15; Mon, 26 Apr 2010 18:12:17 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 7177845F21; Mon, 26 Apr 2010 20:12:14 +0200 (CEST) Received: from localhost (pdawidek.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 4CC9D45F22; Mon, 26 Apr 2010 20:12:10 +0200 (CEST) Date: Mon, 26 Apr 2010 20:12:09 +0200 From: Pawel Jakub Dawidek To: "M. Warner Losh" Message-ID: <20100426181209.GB3012@garage.freebsd.pl> References: <4BD06BD9.6030401@FreeBSD.org> <20100426.103327.319083499807534535.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mxv5cy4qt+RJ9ypb" Content-Disposition: inline In-Reply-To: <20100426.103327.319083499807534535.imp@bsdimp.com> 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=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: mav@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? 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, 26 Apr 2010 18:12:19 -0000 --mxv5cy4qt+RJ9ypb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 26, 2010 at 10:33:27AM -0600, M. Warner Losh wrote: > I've read most of this thread. I think this is cool technology. > However, before we move forward with this, we need to have a plan for > the various issues that have come up. The plan needs to be specific, > have owners for key items, warnings about ownerless =3D=3D obsoleted, and > target dates. >=20 > I think this is one of the cases where we should record the plan of > record on a wiki. It worked well for other times we've had big, > disruptive changes. >=20 > My opinion for the path forward: > (1) Send a big heads up about the future of ataraid(5). It will be > shot in the head soon, to be replaced be a bunch of geom classes > for each different container format. At least that seems to be > the rough consensus I've seen so far. We need worker bees to do > many of these classes, although much can be mined from the ataraid > code today. This shouldn't be a bunch of GEOM classes. This should one class which recognize multiple formats, just like the LABEL class. I don't think it is feasible to reuse gmirror for that, it wasn't designed in something like this in mind. > (2) Send another big heads up strongly recommending people go to > glabel based fstabs. Maybe the right option here is to provide a > simple script walk people through the conversion. This will > render the carnage of ad -> ada (or da) a mostly non-event, and > also protect people from 'oops' of rebooting with that thumb drive > in the system. > (3) Create a wiki to record all the new geom classes needed. Find > people to own each one, or note it is unowned, and support will be > dropped if no owner can be found. > (4) sysinstall should default to creating label systems, if it doesn't > already. > (5) Issues with glabel and ataraid(5) need an owner, and need to be > resolved, since the device names here are likely to change. What are the issues? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --mxv5cy4qt+RJ9ypb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvV13kACgkQForvXbEpPzT6MgCg4JrUw+ONC0VBCXtKBYrfQJXI HV4An28X0VJICNPg3RFHT5+o7MExBaTx =bI6x -----END PGP SIGNATURE----- --mxv5cy4qt+RJ9ypb-- From owner-freebsd-geom@FreeBSD.ORG Mon Apr 26 18:13:20 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 F28CC1065675; Mon, 26 Apr 2010 18:13:20 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id AE87A8FC0A; Mon, 26 Apr 2010 18:13:20 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 443D346B35; Mon, 26 Apr 2010 14:13:20 -0400 (EDT) Date: Mon, 26 Apr 2010 19:13:20 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "M. Warner Losh" In-Reply-To: <20100426.103327.319083499807534535.imp@bsdimp.com> Message-ID: References: <4BD06BD9.6030401@FreeBSD.org> <20100426.103327.319083499807534535.imp@bsdimp.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: mav@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? 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, 26 Apr 2010 18:13:21 -0000 On Mon, 26 Apr 2010, M. Warner Losh wrote: > I've read most of this thread. I think this is cool technology. However, > before we move forward with this, we need to have a plan for the various > issues that have come up. The plan needs to be specific, have owners for > key items, warnings about ownerless == obsoleted, and target dates. > > I think this is one of the cases where we should record the plan of record > on a wiki. It worked well for other times we've had big, disruptive > changes. This is my reading too: this is a big deal change, it's excellent that it's happening, but if we want it to go well we need to do a bit of planning. In particular, if we want to maximize our effectiveness in convincing people to write replacements parts for ataraid, doing the heads up and schedule/warnings the right way will help a lot. While the schedule doesn't need to be as long as the mpsafe network stack/device drivers process, it worked well in practice and so I'd encourage something similar. More generally, and to raise a point not so much in your list: I wonder if global-based fstabs are the right way to go or not. If they are we need to push the migration heavily, and especially provide a pre-upgrade tool to help users get their fstab changes right (i.e., a script that takes your /etc/fstab and system configuration and tells you what to put in your new fstab). I still wonder if we should be trying a bit harder to provide compatibility with the old ata names -- our experience is that "flag day" upgrades cause a lot of user attrition on -current and in the releases, and it might be that making a few architectural sacrifices to ease the upgrade path is worth it. I for one don't want to be on the wrong end of all the users who install a new kernel and discover that /etc/fstab isn't forwards-compatible! All that said: this is really great work, and I'm sure I speak for many when I say thanks to Alexander for the hard work that has gone into this. A bit more perserverence and we'll be there :-). Robert > > My opinion for the path forward: > (1) Send a big heads up about the future of ataraid(5). It will be > shot in the head soon, to be replaced be a bunch of geom classes > for each different container format. At least that seems to be > the rough consensus I've seen so far. We need worker bees to do > many of these classes, although much can be mined from the ataraid > code today. > (2) Send another big heads up strongly recommending people go to > glabel based fstabs. Maybe the right option here is to provide a > simple script walk people through the conversion. This will > render the carnage of ad -> ada (or da) a mostly non-event, and > also protect people from 'oops' of rebooting with that thumb drive > in the system. > (3) Create a wiki to record all the new geom classes needed. Find > people to own each one, or note it is unowned, and support will be > dropped if no owner can be found. > (4) sysinstall should default to creating label systems, if it doesn't > already. > (5) Issues with glabel and ataraid(5) need an owner, and need to be > resolved, since the device names here are likely to change. > (6) Someone needs to write-up a detailed description of how to do this > for UPDATING. Maybe we can reuse text from #2. > (7) We need a target time line for these things to happen. We can't > just break ataraid(5) by default with little or no warning. > Realistically, this will be for 9.0 and later systems, so we have > some time before the branch to give warning, as well as pull the > switch and have adequate testing time. > (8) Fill in all the parts that I've missed :) > > Comments? > > Warner > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-geom@FreeBSD.ORG Mon Apr 26 18:28: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 F1363106564A; Mon, 26 Apr 2010 18:28:58 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 8EBE78FC1B; Mon, 26 Apr 2010 18:28:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o3QIJavp060327; Mon, 26 Apr 2010 12:19:36 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 26 Apr 2010 12:19:46 -0600 (MDT) Message-Id: <20100426.121946.506212773266921087.imp@bsdimp.com> To: pjd@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20100426181209.GB3012@garage.freebsd.pl> References: <4BD06BD9.6030401@FreeBSD.org> <20100426.103327.319083499807534535.imp@bsdimp.com> <20100426181209.GB3012@garage.freebsd.pl> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mav@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? 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, 26 Apr 2010 18:28:59 -0000 In message: <20100426181209.GB3012@garage.freebsd.pl> Pawel Jakub Dawidek writes: : On Mon, Apr 26, 2010 at 10:33:27AM -0600, M. Warner Losh wrote: : > I've read most of this thread. I think this is cool technology. : > However, before we move forward with this, we need to have a plan for : > the various issues that have come up. The plan needs to be specific, : > have owners for key items, warnings about ownerless == obsoleted, and : > target dates. : > : > I think this is one of the cases where we should record the plan of : > record on a wiki. It worked well for other times we've had big, : > disruptive changes. : > : > My opinion for the path forward: : > (1) Send a big heads up about the future of ataraid(5). It will be : > shot in the head soon, to be replaced be a bunch of geom classes : > for each different container format. At least that seems to be : > the rough consensus I've seen so far. We need worker bees to do : > many of these classes, although much can be mined from the ataraid : > code today. : : This shouldn't be a bunch of GEOM classes. This should one class which : recognize multiple formats, just like the LABEL class. : I don't think it is feasible to reuse gmirror for that, it wasn't : designed in something like this in mind. OK. Maybe I got the consensus wrong... My key point is that we need a plan moving forward, we need to identify what's actively being worked on vs "somebody else[tm] should do tihs" and when it needs to be done "or else". : > (2) Send another big heads up strongly recommending people go to : > glabel based fstabs. Maybe the right option here is to provide a : > simple script walk people through the conversion. This will : > render the carnage of ad -> ada (or da) a mostly non-event, and : > also protect people from 'oops' of rebooting with that thumb drive : > in the system. : > (3) Create a wiki to record all the new geom classes needed. Find : > people to own each one, or note it is unowned, and support will be : > dropped if no owner can be found. : > (4) sysinstall should default to creating label systems, if it doesn't : > already. : > (5) Issues with glabel and ataraid(5) need an owner, and need to be : > resolved, since the device names here are likely to change. : : What are the issues? ataraid doesn't remove the underlying ad* devices, so glabel often picks those up instead of the ataraid device, and you only get 1 disk's worth of raid device... So no mirroring or only 1/2 a striped volume. Warner From owner-freebsd-geom@FreeBSD.ORG Mon Apr 26 19:10:24 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 E4B4A106566C; Mon, 26 Apr 2010 19:10:23 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 2775D8FC18; Mon, 26 Apr 2010 19:10:22 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id A835845E35; Mon, 26 Apr 2010 21:10:20 +0200 (CEST) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 1A04745E97; Mon, 26 Apr 2010 21:10:14 +0200 (CEST) Date: Mon, 26 Apr 2010 21:10:12 +0200 From: Pawel Jakub Dawidek To: "M. Warner Losh" Message-ID: <20100426191012.GA1711@garage.freebsd.pl> References: <4BD06BD9.6030401@FreeBSD.org> <20100426.103327.319083499807534535.imp@bsdimp.com> <20100426181209.GB3012@garage.freebsd.pl> <20100426.121946.506212773266921087.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline In-Reply-To: <20100426.121946.506212773266921087.imp@bsdimp.com> 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: mav@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? 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, 26 Apr 2010 19:10:24 -0000 --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 26, 2010 at 12:19:46PM -0600, M. Warner Losh wrote: > In message: <20100426181209.GB3012@garage.freebsd.pl> > Pawel Jakub Dawidek writes: > : On Mon, Apr 26, 2010 at 10:33:27AM -0600, M. Warner Losh wrote: > : > I've read most of this thread. I think this is cool technology. > : > However, before we move forward with this, we need to have a plan for > : > the various issues that have come up. The plan needs to be specific, > : > have owners for key items, warnings about ownerless =3D=3D obsoleted,= and > : > target dates. > : >=20 > : > I think this is one of the cases where we should record the plan of > : > record on a wiki. It worked well for other times we've had big, > : > disruptive changes. > : >=20 > : > My opinion for the path forward: > : > (1) Send a big heads up about the future of ataraid(5). It will be > : > shot in the head soon, to be replaced be a bunch of geom classes > : > for each different container format. At least that seems to be > : > the rough consensus I've seen so far. We need worker bees to do > : > many of these classes, although much can be mined from the ataraid > : > code today. > :=20 > : This shouldn't be a bunch of GEOM classes. This should one class which > : recognize multiple formats, just like the LABEL class. > : I don't think it is feasible to reuse gmirror for that, it wasn't > : designed in something like this in mind. >=20 > OK. Maybe I got the consensus wrong... My key point is that we need > a plan moving forward, we need to identify what's actively being > worked on vs "somebody else[tm] should do tihs" and when it needs to > be done "or else". You most likely got it right, I'm just saying creating separate GEOM class for each metadata format is wrong direction. :) > : > (5) Issues with glabel and ataraid(5) need an owner, and need to be > : > resolved, since the device names here are likely to change. > :=20 > : What are the issues? >=20 > ataraid doesn't remove the underlying ad* devices, so glabel often > picks those up instead of the ataraid device, and you only get 1 > disk's worth of raid device... So no mirroring or only 1/2 a striped > volume. It not only leave ad* devices, it doesn't even open them properly using GEOM. It's internal ATA hack, which is PITA. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --cNdxnHkX5QqsyA0e Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvV5RQACgkQForvXbEpPzTregCg0NfgcdQonjy4PBIFQ+7EQJsU Md8An1JWmyXVZuTwnO0xAqqVUrjXKDqo =K6k2 -----END PGP SIGNATURE----- --cNdxnHkX5QqsyA0e-- From owner-freebsd-geom@FreeBSD.ORG Mon Apr 26 19:54:56 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 88DCB106566B; Mon, 26 Apr 2010 19:54:56 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3FBDD8FC13; Mon, 26 Apr 2010 19:54:56 +0000 (UTC) Received: from desktop.home.serebryakov.spb.ru (85-142-52-164.well-com.net [85.142.52.164]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 0B2D013DF5D; Mon, 26 Apr 2010 23:48:17 +0400 (MSD) Date: Mon, 26 Apr 2010 23:48:08 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <609355278.20100426234808@serebryakov.spb.ru> To: Pawel Jakub Dawidek In-Reply-To: <20100426191012.GA1711@garage.freebsd.pl> References: <4BD06BD9.6030401@FreeBSD.org> <20100426.103327.319083499807534535.imp@bsdimp.com> <20100426181209.GB3012@garage.freebsd.pl> <20100426.121946.506212773266921087.imp@bsdimp.com> <20100426191012.GA1711@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: mav@FreeBSD.org, freebsd-current@FreeBSD.org, "M. Warner Losh" , freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 19:54:56 -0000 Hello, Pawel. You wrote 26 =E0=EF=F0=E5=EB=FF 2010 =E3., 23:10:12: > You most likely got it right, I'm just saying creating separate GEOM > class for each metadata format is wrong direction. :) Does ataraid translations and checksuming (in case of RAID5) now or it configures chipsets only? All these ``raids'' are known as ``soft raids'' or ``fake raids'', but what does do real work -- BIOS or driver (Ataraid in case of FreeBSD)? --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Tue Apr 27 02:57: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 D0A351065673; Tue, 27 Apr 2010 02:57:52 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 4571C8FC1B; Tue, 27 Apr 2010 02:57:51 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.44]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o3R2bDwB035377 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Apr 2010 12:07:19 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=koi8-r From: "Daniel O'Connor" X-Priority: 3 (Normal) In-Reply-To: <609355278.20100426234808@serebryakov.spb.ru> Date: Tue, 27 Apr 2010 12:07:13 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: <035A6E1D-6537-476B-9427-52072E60C41D@gsoft.com.au> References: <4BD06BD9.6030401@FreeBSD.org> <20100426.103327.319083499807534535.imp@bsdimp.com> <20100426181209.GB3012@garage.freebsd.pl> <20100426.121946.506212773266921087.imp@bsdimp.com> <20100426191012.GA1711@garage.freebsd.pl> <609355278.20100426234808@serebryakov.spb.ru> To: lev@freebsd.org X-Mailer: Apple Mail (2.1078) X-Spam-Score: -2.431 () ALL_TRUSTED,AWL,BAYES_00,MIME_CHARSET_FARAWAY X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: mav@freebsd.org, freebsd-current@freebsd.org, Pawel Jakub Dawidek , "M. Warner Losh" , freebsd-geom@freebsd.org Subject: Re: Switchover to CAM ATA? 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, 27 Apr 2010 02:57:52 -0000 On 27/04/2010, at 5:18 AM, Lev Serebryakov wrote: > Hello, Pawel. > You wrote 26 =C1=D0=D2=C5=CC=D1 2010 =C7., 23:10:12: >=20 >> You most likely got it right, I'm just saying creating separate GEOM >> class for each metadata format is wrong direction. :) > Does ataraid translations and checksuming (in case of RAID5) now or > it configures chipsets only? >=20 > All these ``raids'' are known as ``soft raids'' or ``fake raids'', > but what does do real work -- BIOS or driver (Ataraid in case of > FreeBSD)? Both.. ataraid does it when FreeBSD is running but the BIOS does it before then = so boot0, the loader, et al can read the disk without having an = underlying driver. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-geom@FreeBSD.ORG Tue Apr 27 05:55:39 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 5C0B31065672; Tue, 27 Apr 2010 05:55:39 +0000 (UTC) (envelope-from LukeD@pobox.com) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by mx1.freebsd.org (Postfix) with ESMTP id 21C038FC14; Tue, 27 Apr 2010 05:55:38 +0000 (UTC) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 77256AEBA3; Tue, 27 Apr 2010 01:39:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from :reply-to:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; s=sasl; bh=jzcgKvEzBB2Y7OPElAHOjGd7h XA=; b=we6efP3X6TJa44wjGWgDRoSAvFaPG/9mc/tdrtCpPepYxPS4sZmcvKa3V 1udrnrTJyno73zQ5Wu9cZopBqI6xrVl6WIFHR4nKNr5biJ/yXzH9XA+6WZ/z0Umc 5MuWfHAHVZaWV2W+Xf6LTtp45zuzY4HhgjR9er6TD7dkUw4Clg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from :reply-to:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; q=dns; s=sasl; b=q6ZCGkyJvyFNwimYaAV t921/GFe4mzlvoi59hHUG3jECYlj5qQZQTiUVlQ3eGXyj6FkAf2y0iO2HjooEt0h DCJuBUVIt0Z2Px2HZbsLp52vgd+Z7LKv4OKQlXboSvaOQDZFQ8wTK3UmBYrWh1Ss /AkqFpYD7sug4jjTgCTbIGRE= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 538E0AEB9E; Tue, 27 Apr 2010 01:39:09 -0400 (EDT) Received: from lukas.is-a-geek.org (unknown [71.112.198.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 712E7AEB9D; Tue, 27 Apr 2010 01:39:06 -0400 (EDT) Date: Mon, 26 Apr 2010 22:39:02 -0700 (PDT) From: Luke Dean X-X-Sender: lukas@border.lukas.is-a-geek.org To: Alexander Motin In-Reply-To: <4BD06BD9.6030401@FreeBSD.org> Message-ID: References: <4BD06BD9.6030401@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Pobox-Relay-ID: 33BE711E-51BF-11DF-AD23-D033EE7EF46B-96347044!a-pb-sasl-quonix.pobox.com Cc: FreeBSD-Current , freebsd-geom@freebsd.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Luke Dean List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 05:55:39 -0000 On Thu, 22 Apr 2010, Alexander Motin wrote: > So what is the public opinion: Is the lack of ataraid(4) fatal or we can > live without it? Hardware mirroring is very important to me. It's the only solution I'm aware of for realtime protection from drive failure in systems that boot multiple operating systems. From owner-freebsd-geom@FreeBSD.ORG Tue Apr 27 11:41:07 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 A5D2E106566C; Tue, 27 Apr 2010 11:41:07 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 02ABD8FC13; Tue, 27 Apr 2010 11:41:06 +0000 (UTC) Received: by bwz8 with SMTP id 8so12168224bwz.3 for ; Tue, 27 Apr 2010 04:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=dkqWsNhpdJCmDkefQbf3oauoTh+cHZaW9DiJb0M1dPc=; b=I1V60HnlFQoO+iY0phCCDA/q4h3Qu098PE/Ye3mAKk1Yf925airStM0KUzgLv7l1Cl GMqZfZZ8bjkPEgrsytDq92uqzVZ/VsFaBKofNspFIqY7u43XbCF2cE8pwGTs996DU3ET vymkavFhJPHafCaYKW/wWsg/FhzvHJCP6NYe4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=qjuDS19tvdLdmNsy5Cop3euT0TvwDjais9FZP9b9zEAny/ZfnTTgiPRLdbx01+KOrY aMih/iwU0wJeOuaPrCxH+Y1i/CFmHRox2MO+Uj5bn76kBfv53uG8M5l/i5clXzXAnnZ1 mfSy4QP5d8rFaE6b/n9fc9nTekYPqI9TSLpgU= Received: by 10.102.254.26 with SMTP id b26mr3140413mui.118.1272368462295; Tue, 27 Apr 2010 04:41:02 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 14sm21567922muo.16.2010.04.27.04.41.01 (version=SSLv3 cipher=RC4-MD5); Tue, 27 Apr 2010 04:41:01 -0700 (PDT) Sender: Alexander Motin Message-ID: <4BD6CD3F.5080903@FreeBSD.org> Date: Tue, 27 Apr 2010 14:40:47 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Gavin Atkinson References: <4BD06BD9.6030401@FreeBSD.org> <20100426.103327.319083499807534535.imp@bsdimp.com> <1272367989.97887.47.camel@buffy.york.ac.uk> In-Reply-To: <1272367989.97887.47.camel@buffy.york.ac.uk> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? 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, 27 Apr 2010 11:41:07 -0000 Gavin Atkinson wrote: > Losing ataraid would be bad. I suspect there are a lot of installs > using it - especially as there is no way to create any other mirror from > sysinstall. However, I'm not actually sure that the functionality it > provides is easy to push down into GEOM. > > ataraid depends on knowing a lot about the underlying hardware, in order > to know which format of metadata to use. i.e. it needs to know that the > disks are attached to (say) a Highpoint controller. This is especially > important when creating new ATA RAID devices, although there is so > little identifying metadata on the disks themselves that in some cases > it doesn't look like it is possible to identify or even confirm the > existence of metadata without knowing the PCI ID of the controller to > which the disks are attached. > > I'm not sure I can see a way to do this from within GEOM. CAM allows every SIM driver to report several arbitrary string values, describing driver and hardware. They are almost unused now. I don't see much problems in exporting them to GEOM and making tasting method to analyze them. -- Alexander Motin From owner-freebsd-geom@FreeBSD.ORG Tue Apr 27 12:04:28 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 7DD591065673 for ; Tue, 27 Apr 2010 12:04:28 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw2.york.ac.uk (mail-gw2.york.ac.uk [144.32.128.247]) by mx1.freebsd.org (Postfix) with ESMTP id 703058FC13 for ; Tue, 27 Apr 2010 12:04:22 +0000 (UTC) Received: from mail-gw7.york.ac.uk (mail-gw7.york.ac.uk [144.32.129.30]) by mail-gw2.york.ac.uk (8.13.6/8.13.6) with ESMTP id o3RBXAee002203; Tue, 27 Apr 2010 12:33:10 +0100 (BST) Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw7.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1O6j2M-0005cL-Mq; Tue, 27 Apr 2010 12:33:10 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.3/8.14.3) with ESMTP id o3RBXA3b098505; Tue, 27 Apr 2010 12:33:10 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.3/8.14.3/Submit) id o3RBXAvH098504; Tue, 27 Apr 2010 12:33:10 +0100 (BST) (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: "M. Warner Losh" In-Reply-To: <20100426.103327.319083499807534535.imp@bsdimp.com> References: <4BD06BD9.6030401@FreeBSD.org> <20100426.103327.319083499807534535.imp@bsdimp.com> Content-Type: text/plain; charset="ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Apr 2010 12:33:09 +0100 Message-ID: <1272367989.97887.47.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: mav@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? 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, 27 Apr 2010 12:04:28 -0000 On Mon, 2010-04-26 at 10:33 -0600, M. Warner Losh wrote: > My opinion for the path forward: > (1) Send a big heads up about the future of ataraid(5). It will be > shot in the head soon, to be replaced be a bunch of geom classes > for each different container format. At least that seems to be > the rough consensus I've seen so far. We need worker bees to do > many of these classes, although much can be mined from the ataraid > code today. Losing ataraid would be bad. I suspect there are a lot of installs using it - especially as there is no way to create any other mirror from sysinstall. However, I'm not actually sure that the functionality it provides is easy to push down into GEOM. ataraid depends on knowing a lot about the underlying hardware, in order to know which format of metadata to use. i.e. it needs to know that the disks are attached to (say) a Highpoint controller. This is especially important when creating new ATA RAID devices, although there is so little identifying metadata on the disks themselves that in some cases it doesn't look like it is possible to identify or even confirm the existence of metadata without knowing the PCI ID of the controller to which the disks are attached. I'm not sure I can see a way to do this from within GEOM. Gavin From owner-freebsd-geom@FreeBSD.ORG Tue Apr 27 13:30:54 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 B11751065672; Tue, 27 Apr 2010 13:30:54 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 7168D8FC32; Tue, 27 Apr 2010 13:30:54 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 4C4191FFC51; Tue, 27 Apr 2010 13:30:53 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id DF63E84523; Tue, 27 Apr 2010 15:30:20 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Freddie Cash References: <4BD06BD9.6030401@FreeBSD.org> Date: Tue, 27 Apr 2010 15:30:20 +0200 In-Reply-To: (Freddie Cash's message of "Thu, 22 Apr 2010 08:42:04 -0700") Message-ID: <86sk6h3tw3.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: Switchover to CAM ATA? 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, 27 Apr 2010 13:30:54 -0000 Freddie Cash writes: > If a lowly user's vote counts for anything, I'd vote for the complete > removal of ataraid support. We have gstripe, gmirror, graid3, graid5, and > zfs (and gvinum for the masochistics). :) We don't need to support any = of > the crappy pseudo-raid "hardware" out there. ataraid(4) has served it's > purpose, tiding us over until GEOM RAID facilities were in place. Now it= 's > time for it to be retired. gstripe can't create a bootable striped set; ataraid can. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-geom@FreeBSD.ORG Tue Apr 27 13:34:48 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 987871065670; Tue, 27 Apr 2010 13:34:48 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 5180B8FC0A; Tue, 27 Apr 2010 13:34:48 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 5E6101FFC22; Tue, 27 Apr 2010 13:34:47 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id F1D1984523; Tue, 27 Apr 2010 15:34:14 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Maxim Sobolev References: <4BD06BD9.6030401@FreeBSD.org> <4BD099E6.6000402@FreeBSD.org> <4BD0A689.8000508@thekeelecentre.com> <4BD0ACD2.3040805@FreeBSD.org> Date: Tue, 27 Apr 2010 15:34:14 +0200 In-Reply-To: <4BD0ACD2.3040805@FreeBSD.org> (Maxim Sobolev's message of "Thu, 22 Apr 2010 13:08:50 -0700") Message-ID: <86och53tpl.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Alexander Motin , FreeBSD-Current , Richard Tector , freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? 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, 27 Apr 2010 13:34:48 -0000 Maxim Sobolev writes: > Richard Tector writes: > > Could I also add that the removal of ataraid would affect those > > users who dual-boot with Windows and rely on the psuedo-raid > > provided by most Intel chipsets to be able to share the same pair of > > disks. > Well, this won't be a problem if we have GEOM classes that can > understand metadata created by the ATA RAID BIOS(es). Most pseudo-raid kit has nifty features like checksum offloading, composite writes etc. which can improve performance considerably. You can't access those from GEOM. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-geom@FreeBSD.ORG Tue Apr 27 14:00:15 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 DEE991065672; Tue, 27 Apr 2010 14:00:15 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id DB02B8FC1D; Tue, 27 Apr 2010 14:00:11 +0000 (UTC) Received: by ewy24 with SMTP id 24so3985066ewy.33 for ; Tue, 27 Apr 2010 07:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=6HEfOoOq1/j2SHU/Txa/LgniEPqJi+ozw7civoJuLB4=; b=mGdQpsi/C3CR8J6gfeXpoPQUHT48iVywUbbpPyajcVUMTf4SxydM5ta0DjDWqlMwy/ lF80vebL4OJhR/KYDOCK8nY101BsMuz/JSbLGoINFvIT08LZ7MYVLsJc17Yuq6XbCcb1 Xd/CkjS5gvFZGi/uahhqjbTQ0RrA2l873wZt8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=ICyjSST0gEYGsRTz11r3iv6dnpEr12ZB3FVnpxbo6Pt/U3L7dqk5PPP6skrM0a7gId mQAZwKqUCXnoDMb/Nf2Ss4u9tCdDp9s3Rm9uhfB+Ej4LvbemGrw+b6IZRigjDKkxzh+S QzYfMNGgkcS2jqFSFnJ3yfwaVJX+VsAQ1X3bI= Received: by 10.103.133.7 with SMTP id k7mr3196523mun.128.1272376805450; Tue, 27 Apr 2010 07:00:05 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id j10sm22240921mue.48.2010.04.27.07.00.04 (version=SSLv3 cipher=RC4-MD5); Tue, 27 Apr 2010 07:00:04 -0700 (PDT) Sender: Alexander Motin Message-ID: <4BD6EDD6.8010403@FreeBSD.org> Date: Tue, 27 Apr 2010 16:59:50 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <4BD06BD9.6030401@FreeBSD.org> <4BD099E6.6000402@FreeBSD.org> <4BD0A689.8000508@thekeelecentre.com> <4BD0ACD2.3040805@FreeBSD.org> <86och53tpl.fsf@ds4.des.no> In-Reply-To: <86och53tpl.fsf@ds4.des.no> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Maxim Sobolev , FreeBSD-Current , Richard Tector , freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? 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, 27 Apr 2010 14:00:16 -0000 Dag-Erling Smørgrav wrote: > Maxim Sobolev writes: >> Richard Tector writes: >>> Could I also add that the removal of ataraid would affect those >>> users who dual-boot with Windows and rely on the psuedo-raid >>> provided by most Intel chipsets to be able to share the same pair of >>> disks. >> Well, this won't be a problem if we have GEOM classes that can >> understand metadata created by the ATA RAID BIOS(es). > > Most pseudo-raid kit has nifty features like checksum offloading, > composite writes etc. which can improve performance considerably. You > can't access those from GEOM. Have you ever seen them documented? Does the need to specifically handle dozens of incompatible implementations with limited resources worth those (probably not major) benefits? -- Alexander Motin From owner-freebsd-geom@FreeBSD.ORG Tue Apr 27 14:17:03 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 1275D106566C; Tue, 27 Apr 2010 14:17:03 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id C34AD8FC0C; Tue, 27 Apr 2010 14:17:02 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id C200D1FFC51; Tue, 27 Apr 2010 14:17:01 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 656DB84523; Tue, 27 Apr 2010 16:16:29 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alexander Motin References: <4BD06BD9.6030401@FreeBSD.org> <4BD099E6.6000402@FreeBSD.org> <4BD0A689.8000508@thekeelecentre.com> <4BD0ACD2.3040805@FreeBSD.org> <86och53tpl.fsf@ds4.des.no> <4BD6EDD6.8010403@FreeBSD.org> Date: Tue, 27 Apr 2010 16:16:29 +0200 In-Reply-To: <4BD6EDD6.8010403@FreeBSD.org> (Alexander Motin's message of "Tue, 27 Apr 2010 16:59:50 +0300") Message-ID: <86fx2h3rr6.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Maxim Sobolev , FreeBSD-Current , Richard Tector , freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? 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, 27 Apr 2010 14:17:03 -0000 Alexander Motin writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Most pseudo-raid kit has nifty features like checksum offloading, > > composite writes etc. which can improve performance considerably. You > > can't access those from GEOM. > Have you ever seen them documented? ISTR I got the info from sos@ at some point. I have several Promise cards lying around and was working onm RAID5 offloading, but I stopped when ZFS became usable. > Does the need to specifically handle dozens of incompatible > implementations with limited resources worth those (probably not > major) benefits? The details probably vary from controller to controller, but the capabilities are pretty much the same: perform the same write operation to several disks at once, split a write operation across several disks, compute and write parity. IIRC, composite writes are already supported but not used. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-geom@FreeBSD.ORG Tue Apr 27 14:41:46 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 D2DC81065672; Tue, 27 Apr 2010 14:41:46 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id 0CC1F8FC19; Tue, 27 Apr 2010 14:41:45 +0000 (UTC) Received: by ewy24 with SMTP id 24so4022603ewy.33 for ; Tue, 27 Apr 2010 07:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=CnFhT2EW2zhgVncf+lxqj47R4Wi90gKpDctsVM23k00=; b=HrPE5Jc726ixDcqg1mnLYWhXVGO5vesG5C9IhAa8+kJQdICk3zG7YqXbwYsP6lqvcp DXV8oxfwh1o1SqOcIXXHqSCXgF35TIv7n7c8kQzBQlbwWglSoeXMc97zKoDBOW8xs3Uy LxiCwsU/n1fsprVv19uHfVKXeFc2LdxdxBhRk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=Lw0hXWLIfD6Y6hNF5RjrdaQ9eq4xdVKSN7+Qcs64mOfy3ANFgOn1Us8YX2CNkLa+SV MA9PqXMy3rKysXhho5xEtDKwzLeXkL1b2FFdpj1V8UZHiBq82V2Wu9ptQhN0jaOvpGDT sn1kbh5iKluGZg7HTVAQDpE3Cm9uo7AS6Sjmk= Received: by 10.102.216.24 with SMTP id o24mr3225033mug.67.1272379301653; Tue, 27 Apr 2010 07:41:41 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id e10sm22401360muf.8.2010.04.27.07.41.40 (version=SSLv3 cipher=RC4-MD5); Tue, 27 Apr 2010 07:41:41 -0700 (PDT) Sender: Alexander Motin Message-ID: <4BD6F797.5090205@FreeBSD.org> Date: Tue, 27 Apr 2010 17:41:27 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <4BD06BD9.6030401@FreeBSD.org> <4BD099E6.6000402@FreeBSD.org> <4BD0A689.8000508@thekeelecentre.com> <4BD0ACD2.3040805@FreeBSD.org> <86och53tpl.fsf@ds4.des.no> <4BD6EDD6.8010403@FreeBSD.org> <86fx2h3rr6.fsf@ds4.des.no> In-Reply-To: <86fx2h3rr6.fsf@ds4.des.no> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Maxim Sobolev , FreeBSD-Current , Richard Tector , freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? 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, 27 Apr 2010 14:41:47 -0000 Dag-Erling Smørgrav wrote: > Alexander Motin writes: >> Dag-Erling Smørgrav writes: >>> Most pseudo-raid kit has nifty features like checksum offloading, >>> composite writes etc. which can improve performance considerably. You >>> can't access those from GEOM. >> Have you ever seen them documented? > > ISTR I got the info from sos@ at some point. I have several Promise > cards lying around and was working onm RAID5 offloading, but I stopped > when ZFS became usable. Out Promise driver doesn't even have ATAPI support, not speaking about more advanced features. >> Does the need to specifically handle dozens of incompatible >> implementations with limited resources worth those (probably not >> major) benefits? > > The details probably vary from controller to controller, but the > capabilities are pretty much the same: perform the same write operation > to several disks at once, split a write operation across several disks, > compute and write parity. > > IIRC, composite writes are already supported but not used. I haven't dug really deep into current ataraid(4), but AFAIK it is all done in software. At least there is no any offloading support on the controller drivers level. None of ata(4) drivers do anything except executing one ATA command at a time. Looking that most of modern controllers threat every SATA channel independently, with separate request queue, status, interrupts and so on, I can hardly imagine how could they partially accelerate such things. The only alike example I know is a parity calculation accelerator in Marvel ARM SoCs. But it is completely separate device, unrelated to SATA controller. Any URLs? -- Alexander Motin From owner-freebsd-geom@FreeBSD.ORG Tue Apr 27 14:49:35 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 2A4B91065670; Tue, 27 Apr 2010 14:49:35 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id D3BEF8FC15; Tue, 27 Apr 2010 14:49:34 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.3/8.14.3) with ESMTP id o3REnQFU003767; Tue, 27 Apr 2010 08:49:26 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: Scott Long In-Reply-To: <86och53tpl.fsf@ds4.des.no> Date: Tue, 27 Apr 2010 08:49:26 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <70151EE0-AD49-4BB3-ADEB-68447A36D88A@samsco.org> References: <4BD06BD9.6030401@FreeBSD.org> <4BD099E6.6000402@FreeBSD.org> <4BD0A689.8000508@thekeelecentre.com> <4BD0ACD2.3040805@FreeBSD.org> <86och53tpl.fsf@ds4.des.no> To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= X-Mailer: Apple Mail (2.1078) X-Spam-Status: No, score=-0.4 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD, URIBL_SBL autolearn=no version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: Maxim Sobolev , Alexander Motin , FreeBSD-Current , Richard Tector , freebsd-geom@freebsd.org Subject: Re: Switchover to CAM ATA? 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, 27 Apr 2010 14:49:35 -0000 On Apr 27, 2010, at 7:34 AM, Dag-Erling Sm=F8rgrav wrote: > Maxim Sobolev writes: >> Richard Tector writes: >>> Could I also add that the removal of ataraid would affect those >>> users who dual-boot with Windows and rely on the psuedo-raid >>> provided by most Intel chipsets to be able to share the same pair of >>> disks. >> Well, this won't be a problem if we have GEOM classes that can >> understand metadata created by the ATA RAID BIOS(es). >=20 > Most pseudo-raid kit has nifty features like checksum offloading, > composite writes etc. which can improve performance considerably. You > can't access those from GEOM. If my "most" you mean "a small subset of vendors and products", then = yes, you're correct. For the vast remaining majority, all you get is a = special BIOS that can do striping and mirroring at boot. Sometimes that = special BIOS requires a special hook in the controller chip, which is = why you have ICHxxR vs ICHxx chips, for example. All the 'R' means is = that the silicon supports an external ROM. Scott From owner-freebsd-geom@FreeBSD.ORG Tue Apr 27 19:11:28 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 315EA1065677; Tue, 27 Apr 2010 19:11:28 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id E2A698FC1D; Tue, 27 Apr 2010 19:11:27 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.3/8.14.3) with ESMTP id o3RJBM5T004732; Tue, 27 Apr 2010 13:11:23 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: Date: Tue, 27 Apr 2010 13:11:22 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BD06BD9.6030401@FreeBSD.org> To: Luke Dean X-Mailer: Apple Mail (2.1078) X-Spam-Status: No, score=-1.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: Alexander Motin , FreeBSD-Current , freebsd-geom@freebsd.org Subject: Re: Switchover to CAM ATA? 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, 27 Apr 2010 19:11:28 -0000 On Apr 26, 2010, at 11:39 PM, Luke Dean wrote: >=20 >=20 > On Thu, 22 Apr 2010, Alexander Motin wrote: >=20 >> So what is the public opinion: Is the lack of ataraid(4) fatal or we = can >> live without it? >=20 > Hardware mirroring is very important to me. It's the only solution = I'm aware of for realtime protection from drive failure in systems that = boot multiple operating systems. ATARAID doesn't do hardware mirroring. If you need that feature, buy an = MPT card or a real RAID controller. Scott From owner-freebsd-geom@FreeBSD.ORG Tue Apr 27 19:13: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 D33031065674; Tue, 27 Apr 2010 19:13:41 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 752A88FC1B; Tue, 27 Apr 2010 19:13:41 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.3/8.14.3) with ESMTP id o3RJDb8h004747; Tue, 27 Apr 2010 13:13:37 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <1272367989.97887.47.camel@buffy.york.ac.uk> Date: Tue, 27 Apr 2010 13:13:37 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <31A502A0-DB53-4677-BF92-6DD826ED449C@samsco.org> References: <4BD06BD9.6030401@FreeBSD.org> <20100426.103327.319083499807534535.imp@bsdimp.com> <1272367989.97887.47.camel@buffy.york.ac.uk> To: Gavin Atkinson X-Mailer: Apple Mail (2.1078) X-Spam-Status: No, score=-1.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: mav@FreeBSD.org, freebsd-current@FreeBSD.org, "M. Warner Losh" , freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? 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, 27 Apr 2010 19:13:41 -0000 On Apr 27, 2010, at 5:33 AM, Gavin Atkinson wrote: > On Mon, 2010-04-26 at 10:33 -0600, M. Warner Losh wrote: >> My opinion for the path forward: >> (1) Send a big heads up about the future of ataraid(5). It will be >> shot in the head soon, to be replaced be a bunch of geom classes >> for each different container format. At least that seems to be >> the rough consensus I've seen so far. We need worker bees to do >> many of these classes, although much can be mined from the ataraid >> code today. >=20 > Losing ataraid would be bad. I suspect there are a lot of installs > using it - especially as there is no way to create any other mirror = from > sysinstall. However, I'm not actually sure that the functionality it > provides is easy to push down into GEOM. >=20 > ataraid depends on knowing a lot about the underlying hardware, in = order > to know which format of metadata to use. i.e. it needs to know that = the > disks are attached to (say) a Highpoint controller. This is unfortunately true, especially on older controllers. I think = that there are reasonable ways to address this though, by having CAM SIMs provide a bit more information in their PATH_INQ response. Scott From owner-freebsd-geom@FreeBSD.ORG Wed Apr 28 07:35: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 3350A106566C; Wed, 28 Apr 2010 07:35:52 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id E1B248FC15; Wed, 28 Apr 2010 07:35:51 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 279C21FFC53; Wed, 28 Apr 2010 07:35:50 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id A9C8E844F3; Wed, 28 Apr 2010 09:35:17 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alexander Motin References: <4BD06BD9.6030401@FreeBSD.org> <4BD099E6.6000402@FreeBSD.org> <4BD0A689.8000508@thekeelecentre.com> <4BD0ACD2.3040805@FreeBSD.org> <86och53tpl.fsf@ds4.des.no> <4BD6EDD6.8010403@FreeBSD.org> <86fx2h3rr6.fsf@ds4.des.no> <4BD6F797.5090205@FreeBSD.org> Date: Wed, 28 Apr 2010 09:35:17 +0200 In-Reply-To: <4BD6F797.5090205@FreeBSD.org> (Alexander Motin's message of "Tue, 27 Apr 2010 17:41:27 +0300") Message-ID: <86wrvst4ga.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Maxim Sobolev , FreeBSD-Current , Richard Tector , freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? 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: Wed, 28 Apr 2010 07:35:52 -0000 Alexander Motin writes: > I haven't dug really deep into current ataraid(4), but AFAIK it is all > done in software. At least there is no any offloading support on the > controller drivers level. None of ata(4) drivers do anything except > executing one ATA command at a time. Correct. That doesn't mean they *shouldn't* use offloading. Like I said, I started working on checksum offloading for Promise SATA controllers, but ZFS came along and I replaced the controllers because of data corruption issues (which turned out to be either a driver bug or a PCI timing bug which sos@ worked around in the driver, I forget which) > Any URLs? Google "Promise FastTrak SATA RAID" I have two or three of those, including one with on-board SDRAM (but no battery backup) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-geom@FreeBSD.ORG Wed Apr 28 18:20:51 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 1F9B6106564A; Wed, 28 Apr 2010 18:20:51 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id C78428FC15; Wed, 28 Apr 2010 18:20:50 +0000 (UTC) Received: from desktop.home.serebryakov.spb.ru (85-142-52-164.well-com.net [85.142.52.164]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 3501C13DF46; Wed, 28 Apr 2010 22:20:42 +0400 (MSD) Date: Wed, 28 Apr 2010 22:20:39 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1239259726.20100428222039@serebryakov.spb.ru> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= In-Reply-To: <86och53tpl.fsf@ds4.des.no> References: <4BD06BD9.6030401@FreeBSD.org> <4BD099E6.6000402@FreeBSD.org> <4BD0A689.8000508@thekeelecentre.com> <4BD0ACD2.3040805@FreeBSD.org> <86och53tpl.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Maxim Sobolev , Alexander Motin , FreeBSD-Current , Richard Tector , freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 18:20:51 -0000 Hello, Dag-Erling. You wrote 27 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2010 =D0=B3., 17:34:14: > Most pseudo-raid kit has nifty features like checksum offloading, > composite writes etc. Why are they called ``PSEUDO-raids'' then? --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Wed Apr 28 18:32:54 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 097711065672; Wed, 28 Apr 2010 18:32:54 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id B44A78FC1C; Wed, 28 Apr 2010 18:32:53 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id DE6DB1FFC22; Wed, 28 Apr 2010 18:32:52 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 5BEC2844A8; Wed, 28 Apr 2010 20:32:20 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: lev@FreeBSD.org References: <4BD06BD9.6030401@FreeBSD.org> <4BD099E6.6000402@FreeBSD.org> <4BD0A689.8000508@thekeelecentre.com> <4BD0ACD2.3040805@FreeBSD.org> <86och53tpl.fsf@ds4.des.no> <1239259726.20100428222039@serebryakov.spb.ru> Date: Wed, 28 Apr 2010 20:32:20 +0200 In-Reply-To: <1239259726.20100428222039@serebryakov.spb.ru> (Lev Serebryakov's message of "Wed, 28 Apr 2010 22:20:39 +0400") Message-ID: <86633bv363.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Maxim Sobolev , Alexander Motin , FreeBSD-Current , Richard Tector , freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? 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: Wed, 28 Apr 2010 18:32:54 -0000 Lev Serebryakov writes: > "Dag-Erling Sm=C3=B8rgrav" writes: > > Most pseudo-raid kit has nifty features like checksum offloading, > > composite writes etc. > Why are they called ``PSEUDO-raids'' then? Several reasons - they don't present the array to the OS as a single device, they don't handle failover, etc. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-geom@FreeBSD.ORG Thu Apr 29 18:25:28 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 5645E106564A; Thu, 29 Apr 2010 18:25:28 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2E6CE8FC08; Thu, 29 Apr 2010 18:25:28 +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 o3TIPS5Y046849; Thu, 29 Apr 2010 18:25:28 GMT (envelope-from jh@freefall.freebsd.org) Received: (from jh@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3TIPSD7046845; Thu, 29 Apr 2010 18:25:28 GMT (envelope-from jh) Date: Thu, 29 Apr 2010 18:25:28 GMT Message-Id: <201004291825.o3TIPSD7046845@freefall.freebsd.org> To: jh@FreeBSD.org, freebsd-geom@FreeBSD.org, jh@FreeBSD.org From: jh@FreeBSD.org Cc: Subject: Re: kern/139847: [geom_mbr] [patch] load/unload causes system to hang 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, 29 Apr 2010 18:25:28 -0000 Synopsis: [geom_mbr] [patch] load/unload causes system to hang Responsible-Changed-From-To: freebsd-geom->jh Responsible-Changed-By: jh Responsible-Changed-When: Thu Apr 29 18:25:27 UTC 2010 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=139847