Date: Mon, 12 May 2014 17:44:34 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= <Trond.Endrestol@fagskolen.gjovik.no> To: Matthias Fechner <idefix@fechner.net> Cc: freebsd-questions@freebsd.org Subject: Re: Change block size on ZFS pool Message-ID: <alpine.BSF.2.00.1405121643360.27459@mail.fig.ol.no> In-Reply-To: <5370C1DE.4010805@fechner.net> References: <5370C1DE.4010805@fechner.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 12 May 2014 14:43+0200, Matthias Fechner wrote: > Hi, > > I upgraded now a FreeBSD 9 to version 10. > Now my zpool says: > pool: zroot > state: ONLINE > status: One or more devices are configured to use a non-native block size. > Expect reduced performance. > action: Replace affected devices with devices that support the > configured block size, or migrate data to a properly configured > pool. > scan: scrub repaired 0 in 42h48m with 0 errors on Mon May 5 06:36:10 2014 > config: > > NAME STATE READ > WRITE CKSUM > zroot ONLINE 0 > 0 0 > mirror-0 ONLINE 0 > 0 0 > gptid/504acf1f-5487-11e1-b3f1-001b217b3468 ONLINE 0 > 0 0 block size: 512B configured, 4096B native > gpt/disk1 ONLINE 0 > 0 0 block size: 512B configured, 4096B native > > My partition are aligned to 4k: > => 34 3907029101 ada2 GPT (1.8T) > 34 6 - free - (3.0K) > 40 128 1 freebsd-boot (64K) > 168 8388608 2 freebsd-swap (4.0G) > 8388776 3898640352 3 freebsd-zfs (1.8T) > 3907029128 7 - free - (3.5K) > > But it seems that the ZFS pool is not aligned correctly. > > Is there a possibility to correct that online without taking the pool > offline? No. I can think of one rather dangerous approach, using gpt/disk1 as the victim. However, the real victim is your precious pool and its (then) sole member, gptid/504acf1f-5487-11e1-b3f1-001b217b3468. Mind you, what I propose is dangerous, and untested, and it leaves you with absolutely NO redundancy while performing the steps below. If your zroot pool contains important data, you should consider buying a pair of new harddrives, or at least buy one new harddrive. Partition the new harddrives similar to the existing ones. Create a new mirrored, 4K pool using the gnop trick as shown below and transfer your precious data using a recursive snapshot and the zfs send/receive commands. You have been warned! What follows is a potentially dangerous and untested procedure off the top of my head: 1. Detach one of the mirrors, say gpt/disk1, using: zpool detach zroot gpt/disk1 2. Clear all ZFS labels on gpt/disk1: zpool labelclear gpt/disk1 3. Create a gnop(8) device emulating 4K disk blocks: gnop create -S 4096 /dev/gpt/disk1 4. Create a new single disk zpool named zroot1 using the gnop device as the vdev: zpool create zroot1 gpt/disk1.nop 5. Export the zroot1 pool: zpool export zroot1 6. Destroy the gnop device: gnop destroy /dev/gpt/disk1.nop 7. Reimport the zroot1 pool, searching for vdevs in /dev/gpt: zpool -d /dev/gpt zroot1 8. Create a recursive snapshot on zroot: zfs snapshot -r zroot@transfer 9. Transfer the recursive snapshots from zroot to zroot1, preserving every detail, without mounting the destination filesystems: zfs send -R zroot@transfer | zfs receive -duv zroot1 10. Verify that zroot1 has indeed received all datasets: zfs list -r -t all zroot1 11. Verify, and if necessary, adjust the bootfs property on zroot1: zpool get bootfs zroot1 (If necessary: zpool set bootfs=zroot1/blah/blah/blah zroot1) 12. Reboot the computer into singleuser mode, making sure to boot from the zroot1 pool. If this is not possible, you might need to physically swap the harddrives. 13. Don't perform any zfs mount operations while in singleuser mode as you don't want to deal with any conflicting filesystems from the zroot1 pool and the original zroot pool. 14. Destroy what remains of the original zroot pool: zpool destroy zroot 15. Simply attach gptid/504acf1f-5487-11e1-b3f1-001b217b3468 or, gpt/disk0 if it exists, to the zroot1 pool, using gpt/disk1 as a guide: zpool attach zroot1 gpt/disk1 gptid/504acf1f-5487-11e1-b3f1-001b217b3468 OR zpool attach zroot1 gpt/disk1 gpt/disk0 The latter alternative depends on the gpt label being properly set for the gptid/504acf1f-5487-11e1-b3f1-001b217b3468 partition. 16. Wait patiently while you allow the newly attached mirror to resilver completely. You may want check on the progress by issuing: zpool status -v 17. You might want to rid yourself of the @transfer snapshot: zfs destroy -r zroot1@transfer 18. If you want to rename the zroot1 pool back to zroot, you need to do so from a stable/10 snapshot, CD or memstick, capable of using all the enabled zpool features: zpool import -fN zroot1 zroot Reboot WITHOUT exporting the zroot pool! If you depend on the /boot/zfs/zpool.cache file, you might want to update that file by doing these commands instead: zpool import -fN -o cachefile=/tmp/zpool.cache zroot1 zroot (import any other pools using the -fN -o cachefile=/tmp/zpool.cache options) mkdir /tmp/zroot mount -t zfs zroot /tmp/zroot cp -p /tmp/zpool.cache /tmp/zroot/boot/zfs/zpool.cache Be sure to mount the right dataset, i.e. your bootfs. 19. If you swapped the harddrives in step 12, you might want to rearrange your harddrives back into the right order. Think very carefully about the steps in this laundry list of mine, I might have missed something vital. If possible, first do some experiments on an expendable VM to verify my claims. Creating a new 4K zpool and transfering your data is by far the safer route. I hope someone more knowledgeable on ZFS will chime in if what I propose is clearly mistaken. Be very careful! -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-questions@FreeBSD.ORG Mon May 12 16:29:20 2014 Return-Path: <owner-freebsd-questions@FreeBSD.ORG> Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 33634DE1 for <freebsd-questions@freebsd.org>; Mon, 12 May 2014 16:29:20 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D75732763 for <freebsd-questions@freebsd.org>; Mon, 12 May 2014 16:29:19 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s4CGTIg1001640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 12 May 2014 10:29:18 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s4CGTBYw001637; Mon, 12 May 2014 10:29:18 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Mon, 12 May 2014 10:29:11 -0600 (MDT) From: Warren Block <wblock@wonkity.com> To: "Ronald F. Guilmette" <rfg@tristatelogic.com> Subject: Re: "Secure Boot" motherboards (to avoid)? In-Reply-To: <5061.1399755000@server1.tristatelogic.com> Message-ID: <alpine.BSF.2.00.1405121026570.1395@wonkity.com> References: <5061.1399755000@server1.tristatelogic.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Mon, 12 May 2014 10:29:18 -0600 (MDT) Cc: freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: User questions <freebsd-questions.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-questions>, <mailto:freebsd-questions-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-questions/>; List-Post: <mailto:freebsd-questions@freebsd.org> List-Help: <mailto:freebsd-questions-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-questions>, <mailto:freebsd-questions-request@freebsd.org?subject=subscribe> X-List-Received-Date: Mon, 12 May 2014 16:29:20 -0000 On Sat, 10 May 2014, Ronald F. Guilmette wrote: > > Please forgive what may perhaps be an FAQ, answered somewhere (but noplace > that I can find, apparently). > > I'll be buying a new motherboard soon to replace the aging 6.5 year old > Gigabyte motherboard in my #2 "desktop" system. > > For whatever new motherboard I buy, do I need to be on the lookout > for the possibility that it may incorporate some form of non-easily- > disablable UEFI/SecureBoot firmware that will prevent me from booting > anything other than Windoze? Or is this generally a non-issue for > stand-alone (sold-alone) consumer motherboards? The ability to disable SecureBoot is supposed to be part of the UEFI spec. Just for reference, I recently set up a UEFI Gigabyte H87-D3H for legacy booting. It works fine.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1405121643360.27459>