Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 May 2014 18:55:00 +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.1405121853340.27459@mail.fig.ol.no>
In-Reply-To: <alpine.BSF.2.00.1405121643360.27459@mail.fig.ol.no>
References:  <5370C1DE.4010805@fechner.net> <alpine.BSF.2.00.1405121643360.27459@mail.fig.ol.no>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 12 May 2014 17:44+0200, Trond Endrestøl wrote:

> 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

Sorry, this should read: zpool import -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 18:56:18 2014
Return-Path: <owner-freebsd-questions@FreeBSD.ORG>
Delivered-To: questions@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id 056CC2E4;
 Mon, 12 May 2014 18:56:18 +0000 (UTC)
Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com
 [IPv6:2a00:1450:400c:c00::229])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (verified OK))
 by mx1.freebsd.org (Postfix) with ESMTPS id 6A24F241B;
 Mon, 12 May 2014 18:56:17 +0000 (UTC)
Received: by mail-wg0-f41.google.com with SMTP id z12so7432939wgg.24
 for <multiple recipients>; Mon, 12 May 2014 11:56:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=googlemail.com; s=20120113;
 h=from:date:to:cc:subject:message-id:references:mime-version
 :content-type:content-disposition:in-reply-to:user-agent;
 bh=klzpNQER+1Ny3eZATQsaOhpAmZB7BMfBkhooiie+0dk=;
 b=ZlSUoxzDLH5+LGKKyDmpgItJbFqVV94Aq14gigA0+urwBYiY03SJKNQwjmiVQeJyjc
 GmP12SorhWuoYAxRbAgB+bj8POHXAfMIPHVbvqD6mlSUPu7gMBV4+OWUkngr0Q9Z6dHV
 ut0czyABxH3/Hd7zqCPedcWLz4GI7+mSAiRi8QWPlUgbN1HD9fLKrwaWXNQegE06iEC0
 0h+jeU7Ft1WYwqzrctecaZYcZ7JSrfK6C/e9ozqSldYlfo2GBh1EjtZuPOgp3p7Pg9X0
 9Zu51uE5lPLy6U8mJ1/i5dM5nKvo2a8aB1gWaxDaEM6d+9K3eKXlk8qx28J7skgdw+FZ
 tdTQ==
X-Received: by 10.180.93.101 with SMTP id ct5mr17132789wib.23.1399920975564;
 Mon, 12 May 2014 11:56:15 -0700 (PDT)
Received: from localhost (client-86-29-126-26.glfd.adsl.virginm.net.
 [86.29.126.26])
 by mx.google.com with ESMTPSA id ho2sm17577109wib.15.2014.05.12.11.56.13
 for <multiple recipients>
 (version=TLSv1 cipher=RC4-SHA bits=128/128);
 Mon, 12 May 2014 11:56:14 -0700 (PDT)
X-Google-Original-From: "Peter Harrison" <peter@>
Received: by localhost (sSMTP sendmail emulation);
 Mon, 12 May 2014 19:56:43 +0100
From: Peter Harrison <four.harrisons@googlemail.com>
Date: Mon, 12 May 2014 19:56:42 +0100
To: Adrian Chadd <adrian@freebsd.org>
Subject: Re: Chromium again
Message-ID: <20140512185642.GA1794@thinkpad.piggybox>
References: <20140510194507.GA13714@thinkpad.piggybox>
 <CAJ-VmokK3rqj=FS95h8UgL1fbpba4YD0JAk5R5uK9zKck3Q00w@mail.gmail.com>
 <20140511213702.GA1797@thinkpad.piggybox>
 <CAJ-Vmon9_rke4ZEL=pDBjq02xePmdj0io42MXm5E+oyXJhkerA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAJ-Vmon9_rke4ZEL=pDBjq02xePmdj0io42MXm5E+oyXJhkerA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: questions@freebsd.org, Peter Harrison <four.harrisons@googlemail.com>
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 18:56:18 -0000

Sunday, 11 May 2014 at 15:11:49 -0700, Adrian Chadd said:
> Hi,
> 
> You didn't type in the whole gdb command line I asked you to type in. :-)

Ah. My bad. Sorry. Here we go:

gdb /usr/local/share/chromium/chrome chrome.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)...
Core was generated by `chrome'.
Program terminated with signal 11, Segmentation fault.
#0  0x2e025d68 in ?? ()
(gdb) bt
#0  0x2e025d68 in ?? ()
#1  0x2e021931 in ?? ()
#2  0x00000005 in ?? ()
#3  0xbfbfc420 in ?? ()
#4  0x00000040 in ?? ()
#5  0x0e1de568 in ?? ()
#6  0x32beddd4 in ?? ()
#7  0x2ef9ad34 in ?? ()
#8  0x316bca80 in ?? ()
#9  0x087e26da in std::string::_S_construct<char*> ()
#10 0x32beddd4 in ?? ()
#11 0x0000003e in ?? ()
#12 0xbfbfc378 in ?? ()
#13 0x0e1de568 in ?? ()
#14 0x0e1de568 in ?? ()
#15 0x0e1de568 in ?? ()
#16 0x32bedc00 in ?? ()
#17 0x08a56d31 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string<__gnu_cxx::__normal_iterator<char*, std::string> > ()
#18 0x32beddd4 in ?? ()
#19 0x00000000 in ?? ()
(gdb) 

Thanks for staying with it!



Peter.






> 
> 
> -a
> 
> 
> On 11 May 2014 14:37, Peter Harrison <four.harrisons@googlemail.com> wrote:
> > Sunday, 11 May 2014 at 12:44:47 -0700, Adrian Chadd said:
> >> What's uname -a say?
> >
> > FreeBSD thinkpad.piggybox 9.2-RELEASE-p5 FreeBSD 9.2-RELEASE-p5 #0: Tue Apr 29 18:53:19 UTC 2014     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  i386
> >
> >>
> >> Can you run gdb on the core file?
> >>
> >> gdb /usr/local/share/chromium/chrome chrome.core
> >>
> >> If you can, what's the output of 'bt' in gdb?
> >
> > gdb chrome.core
> > GNU gdb 6.1.1 [FreeBSD]
> > Copyright 2004 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you are
> > welcome to change it and/or distribute copies of it under certain conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for details.
> > This GDB was configured as "i386-marcel-freebsd"..."/usr/home/peter/chrome.core": not in executable format: File format not recognized
> >
> > (gdb) bt
> > No stack.
> > (gdb)
> >
> >
> > I am not an expert, but that doesn't look that helpful I'm afraid - but thanks for coming  back to me.
> >
> >
> >
> > Peter.
> >
> >>
> >>
> >> -a
> >>
> >>
> >> On 10 May 2014 12:45, Peter Harrison <four.harrisons@googlemail.com> wrote:
> >> > OK, so after the fix made yesterday Chromium now compiles.
> >> >
> >> > But it won't run - segfaulting without fail every time. Is anyone else seeing this, or is it just me?
> >> >
> >> > Cheers,
> >> >
> >> >
> >> >
> >> >
> >> > Peter Harrison.
> >> > _______________________________________________
> >> > freebsd-questions@freebsd.org mailing list
> >> > http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> >> > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1405121853340.27459>