Change block size on ZFS pool
Trond Endrestøl
Trond.Endrestol at fagskolen.gjovik.no
Mon May 12 16:55:21 UTC 2014
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 at transfer
>
> 9. Transfer the recursive snapshots from zroot to zroot1, preserving
> every detail, without mounting the destination filesystems:
>
> zfs send -R zroot at 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 at 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. |
+-------------------------------+------------------------------------+
More information about the freebsd-questions
mailing list