Date: Thu, 5 Jan 2012 09:18:59 +0000 From: krad <kraduk@gmail.com> To: Martin Birgmeier <Martin.Birgmeier@aon.at> Cc: freebsd-fs@freebsd.org Subject: Re: Upgrade to 9.0: How to convert zpool from adX to adaX? Message-ID: <CALfReydfJ5odn3hqpeQtez=1fg3pXh4o6WPMePrv=PzbRRQjgw@mail.gmail.com> In-Reply-To: <4F05586B.9060109@aon.at> References: <4F04749E.9020301@aon.at> <20120104172351.GA42855@icarus.home.lan> <4F05586B.9060109@aon.at>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5 January 2012 07:59, Martin Birgmeier <Martin.Birgmeier@aon.at> 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:<JMicron JMB361 UDMA133 controller> 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:<AHCI SATA controller> on atapci0
>>> atapci1: [ITHREAD]
>>> atapci1: AHCI v1.00 controller with 2 3Gbps ports, PM supported
>>> ata2:<ATA channel 0> on atapci1
>>> ata2: [ITHREAD]
>>> ata3:<ATA channel 1> on atapci1
>>> ata3: [ITHREAD]
>>> ata4:<ATA channel 0> on atapci0
>>> ata4: [ITHREAD]
>>> atapci2:<ATI IXP700/800 SATA300 controller> 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:<ATA channel 0> on atapci2
>>> ata5: [ITHREAD]
>>> ata6:<ATA channel 1> on atapci2
>>> ata6: [ITHREAD]
>>> ata7:<ATA channel 2> on atapci2
>>> ata7: [ITHREAD]
>>> ata8:<ATA channel 3> on atapci2
>>> ata8: [ITHREAD]
>>> ata9:<ATA channel 4> on atapci2
>>> ata9: [ITHREAD]
>>> ata10:<ATA channel 5> on atapci2
>>> ata10: [ITHREAD]
>>> ad10: 1907729MB<WDC WD2001FASS-00W2B0 01.00101> at ata5-master
>>> UDMA100 SATA 3Gb/s
>>> ad12: 1907729MB<WDC WD2001FASS-00W2B0 01.00101> at ata6-master
>>> UDMA100 SATA 3Gb/s
>>> ad14: 1907729MB<WDC WD2001FASS-00W2B0 01.00101> at ata7-master
>>> UDMA100 SATA 3Gb/s
>>> ad16: 1907729MB<WDC WD2001FASS-00W2B0 01.00101> at ata8-master
>>> UDMA100 SATA 3Gb/s
>>> ad18: 1907729MB<WDC WD2001FASS-00W2B0 01.00101> at ata9-master
>>> UDMA100 SATA 3Gb/s
>>> ad20: 1907729MB<WDC WD2001FASS-00W2B0 01.00101> 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<http://lists.freebsd.org/mailman/listinfo/freebsd-fs>;
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@**freebsd.org<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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALfReydfJ5odn3hqpeQtez=1fg3pXh4o6WPMePrv=PzbRRQjgw>