Bug 153695 - [patch] [zfs] Booting from zpool created on 4k-sector drive doesn't work
Summary: [patch] [zfs] Booting from zpool created on 4k-sector drive doesn't work
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 8.2-PRERELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs mailing list
Depends on:
Reported: 2011-01-04 23:50 UTC by Emil Smolenski
Modified: 2018-01-03 05:16 UTC (History)
0 users

See Also:

file.diff (1.88 KB, patch)
2011-01-04 23:50 UTC, Emil Smolenski
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Emil Smolenski 2011-01-04 23:50:09 UTC
There is a hack to force zpool creation with minimum sector size equal to 4k:

# gnop create -S 4096 ${DEV0}
# zpool create tank ${DEV0}.nop
# zpool export tank
# gnop destroy ${DEV0}.nop
# zpool import tank

Zpool created this way is faster on problematic 4k sector drives which lies about its sector size (like WD EARS). This hack works perfectly fine when system is running. Gnop layer is created only for "zpool create" command -- ZFS stores information about sector size in its metadata. After zpool creation one can export the pool, remove gnop layer and reimport the pool. Difference can be seen in the output from the zdb command:

- on 512 sector device (2**9 = 512):
% zdb tank |grep ashift

- on 4096 sector device (2**12 = 4096):
% zdb tank |grep ashift

This change is permanent. The only possibility to change the value of  
ashift is: zpool destroy/create and restoring pool from backup.

But there is one problem: I cannot boot from such pool. Error message:

ZFS: i/o error - all block copies unavailable
ZFS: can't read MOS
ZFS: unexpected object set type 0

This is standard configuration with GPT scheme.

# gpart show da0
=>        34  2930211565  da0  GPT  (1.4T)
           34          30       - free -  (15K)
           64         128    1  freebsd-boot  (64K)
          192     4194304    2  freebsd-swap  (2.0G)
      4194496     8388608    3  freebsd-zfs  (4.0G)
     12583104  2917628495       - free -  (1.4T)

# zpool status tank
   pool: tank
  state: ONLINE
  scrub: none requested

         NAME         STATE     READ WRITE CKSUM
         tank         ONLINE       0     0     0
           gpt/tank0  ONLINE       0     0     0

# zdb -uuu tank

         magic = 0000000000bab10c
         version = 15
         txg = 2838
         guid_sum = 12371721502612965633
         timestamp = 1292860198 UTC = Mon Dec 20 15:49:58 2010
         rootbp = [L0 DMU objset] 800L/200P DVA[0]=<0:2041000:1000>  
DVA[1]=<0:30062000:1000> DVA[2]=<0:ee0bd000:1000> fletcher4 lzjb LE contiguous birth=2838 fill=374 cksum=c9605617d:4e2cf0a8c94:f6decb77086a:210752c3aee4a8

This PR is similar to message which I send to freebsd-fs@ mailing list: http://lists.freebsd.org/pipermail/freebsd-fs/2010-December/010350.html

Fix: Attached patch is far from being perfect. I posted it here because maybe it could help someone skilled enough in tracking down this issue and provide proper solution.

With this patch applied:
- I can boot from single disk zpool,
- I can boot from mirrored zpool,
- I can't boot from raidz,
- I can't boot from mirrored zpool created on HP SmartArray P400 (it may be related to bug described in this PR: kern/151910

Patch attached with submission follows:
How-To-Repeat: Install FreeBSD 8.2-PRERELEASE like described here: http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot with following exceptions:

1. Add "-b 32K" to "gpart add -s 64K -t freebsd-boot ad0" command for proper 4k alignment.
2. Issue "gnop create -S 4096 ad0" command before creating zpool.
3. Use .nop device to create zpool.
4. Export the zpool, remove the gnop layer and reimport the zpool.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2011-01-05 02:09:02 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-fs

Over to maintainer(s).
Comment 2 Emil Smolenski 2011-01-22 23:21:39 UTC
Just for reference: pjd@ solved this issue:

Comment 3 Steven Hartland & 2013-03-02 01:43:06 UTC
So this is no longer a problem and can be closed?

This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster@multiplay.co.uk.
Comment 4 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:01:43 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped