From owner-freebsd-fs@FreeBSD.ORG Thu Jan 5 09:19:00 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48E31106566C for ; Thu, 5 Jan 2012 09:19:00 +0000 (UTC) (envelope-from kraduk@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 008EF8FC12 for ; Thu, 5 Jan 2012 09:18:59 +0000 (UTC) Received: by yhfq46 with SMTP id q46so41376yhf.13 for ; Thu, 05 Jan 2012 01:18:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WA9oUARlPirabOs6rlKhwUgLiO1vKlNVZzwlsJHUL+Y=; b=hxQ1rnB0cxls8cXWtZVmgpygNXx50quGkhncszaZmBN3/lbJB3MyLLhc2jyuKMUQZF zJFMxWJzKpQ7BWGc4bxvvTOA7Bsms2H4U3D2VpzWrHo2wWnsIHGlf1EHrHjmVpiaQK1k HUnINT0w0/0JV7AomozgHUCeGfjUWmPYnckqs= MIME-Version: 1.0 Received: by 10.236.78.193 with SMTP id g41mr491038yhe.25.1325755139273; Thu, 05 Jan 2012 01:18:59 -0800 (PST) Received: by 10.236.139.193 with HTTP; Thu, 5 Jan 2012 01:18:59 -0800 (PST) In-Reply-To: <4F05586B.9060109@aon.at> References: <4F04749E.9020301@aon.at> <20120104172351.GA42855@icarus.home.lan> <4F05586B.9060109@aon.at> Date: Thu, 5 Jan 2012 09:18:59 +0000 Message-ID: From: krad To: Martin Birgmeier Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: Upgrade to 9.0: How to convert zpool from adX to adaX? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 09:19:00 -0000 On 5 January 2012 07:59, Martin Birgmeier wrote: > On 01/04/12 18:23, Jeremy Chadwick wrote: > >> On Wed, Jan 04, 2012 at 04:47:42PM +0100, Martin Birgmeier wrote: >> >>> I'll be upgrading a server from 8.2 to 9.0 soon. On it, I currently >>> have the following zpool: >>> >>> ---------- >>> [0]# zpool status >>> pool: hal.1 >>> state: ONLINE >>> status: The pool is formatted using an older on-disk format. The pool >>> can >>> still be used, but some features are unavailable. >>> action: Upgrade the pool using 'zpool upgrade'. Once this is done, the >>> pool will no longer be accessible on older software versions. >>> scrub: none requested >>> config: >>> >>> NAME STATE READ WRITE CKSUM >>> hal.1 ONLINE 0 0 0 >>> raidz2 ONLINE 0 0 0 >>> ad10p3 ONLINE 0 0 0 >>> ad12p3 ONLINE 0 0 0 >>> ad14p3 ONLINE 0 0 0 >>> ad16p3 ONLINE 0 0 0 >>> ad18p3 ONLINE 0 0 0 >>> ad20p3 ONLINE 0 0 0 >>> >>> errors: No known data errors >>> [0]# >>> ---------- >>> >>> I would like to do two things: >>> >>> 1) Wire the ATA CAM disks such that ad10 -> ada0, ad12 -> ada1, etc. >>> >>> 2) Change the zpool to use the then newly available ada0p3, ada1p3, >>> ..., ada5p3 gparts. >>> >>> Ultimately, I want to set sysctl kern.cam.ada.legacy_aliases=0. >>> >>> Please advise on how best to achieve this. >>> >>> Regards, >>> >>> Martin >>> >>> p.s. The following information relates to the current ata attachments: >>> >>> ---------- >>> [0]# egrep 'ad[0-9]|ata[0-9]|atapci[0-9]' /var/run/dmesg.boot >>> atapci0: port >>> 0xcc00-0xcc07,0xc880-0xc883,**0xc800-0xc807,0xc480-0xc483,** >>> 0xc400-0xc40f >>> mem 0xfe8fe000-0xfe8fffff irq 18 at device 0.0 on pci3 >>> atapci0: [ITHREAD] >>> atapci1: on atapci0 >>> atapci1: [ITHREAD] >>> atapci1: AHCI v1.00 controller with 2 3Gbps ports, PM supported >>> ata2: on atapci1 >>> ata2: [ITHREAD] >>> ata3: on atapci1 >>> ata3: [ITHREAD] >>> ata4: on atapci0 >>> ata4: [ITHREAD] >>> atapci2: port >>> 0xa000-0xa007,0x9000-0x9003,**0x8000-0x8007,0x7000-0x7003,** >>> 0x6000-0x600f >>> mem 0xfe4ffc00-0xfe4fffff irq 19 at device 17.0 on pci0 >>> atapci2: [ITHREAD] >>> atapci2: AHCI v1.20 controller with 6 3Gbps ports, PM supported >>> ata5: on atapci2 >>> ata5: [ITHREAD] >>> ata6: on atapci2 >>> ata6: [ITHREAD] >>> ata7: on atapci2 >>> ata7: [ITHREAD] >>> ata8: on atapci2 >>> ata8: [ITHREAD] >>> ata9: on atapci2 >>> ata9: [ITHREAD] >>> ata10: on atapci2 >>> ata10: [ITHREAD] >>> ad10: 1907729MB at ata5-master >>> UDMA100 SATA 3Gb/s >>> ad12: 1907729MB at ata6-master >>> UDMA100 SATA 3Gb/s >>> ad14: 1907729MB at ata7-master >>> UDMA100 SATA 3Gb/s >>> ad16: 1907729MB at ata8-master >>> UDMA100 SATA 3Gb/s >>> ad18: 1907729MB at ata9-master >>> UDMA100 SATA 3Gb/s >>> ad20: 1907729MB at ata10-master >>> UDMA100 SATA 3Gb/s >>> [0]# >>> >> You can try doing this on 8.2 already, and always revert if need be. >> All you need to do is add ahci_load="yes" to /boot/loader.conf and see >> how things behave after that. This will make use of the AHCI-to-CAM >> translation layer (which is now default in 9.0). >> >> There isn't much you need to do with ZFS either: it should "taste" >> the disks and find them on boot. If it doesn't, try "zpool import", >> then when it shows the pool, do "zpool import {poolid}". >> >> It should automatically refer to everything as adaX going forward. >> >> No need to bother with kern.cam.ada.legacy_aliases. >> >> Thank you for this explanation. > > I understand that many improvements to zfs have gone into the code after > 8.2.0; therefore, I am very careful not doing any "exotic" things with this > server, as it is a production system and I do not want to lose data. (Note: > Single and double failures are supposedly covered by using raidz2, and > history is preserved by using snapshots, so I have no further backups on > tapes or other disks. Thus, theoretically, all backup cases except for > disaster are covered, and regarding that I currently count on the > probability of floods, fire, burglary, and Russian Mars probes falling on > my house as being sufficiently low, whereas I am not that confident > regarding software disasters.) To make it short, I do not want to > experiment, but just to apply a tried and true procedure for getting my > pool to operate flawlessly under 9.0. > > Remark: My root partition is a UFS. > > In 9.0, if I keep kern.cam.ada.legacy_aliases=1, there will be two paths > to each device, one through adX, the other through adaX. Which one will zfs > use, and show with 'zpool status'? > > Also, I understand that I will have to wire down the various ATA CAMs to > obtain the old numbering. How can I do this? Again, which path would zfs > use if I did not wire down the ATA CAMs? Will I have half of my devices go > through adX and the other through adaX, or will zfs even believe that it > has a multipath connectivity to each device? > > Regards, > > Martin > > > ______________________________**_________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@**freebsd.org > " > i have upgraded a few of my systems to 9 and they seamlessly went from adX to adaX without any intervention. I am however pure zfs, and its the ufs bit of your system thats likely to be the issue here. Best thing to do if its remote is to make sure you get out of band access (ilom etc) or have a decent set of remote hands. Then if anything goes wrong on the flip over to the new os its not to much of an issue to fix. You should probably consider implementing some form of labeling while you have the down time arranged as if you were doing this rather than using device names you wouldnt have this problem. I livecd/usb would be useful for setting that up