This is an interesting change, could this not cause serious issues when
we try to read / write to a disk with an incompatible block size?

   Regards
   Steve
----- Original Message ----- From: "Xin LI" <delp...@freebsd.org>
To: <src-committ...@freebsd.org>; <svn-src-...@freebsd.org>; 
<svn-src-head@freebsd.org>
Sent: Thursday, July 18, 2013 1:22 AM
Subject: svn commit: r253441 - in head: cddl/contrib/opensolaris/cmd/zpool 
sys/cddl/contrib/opensolaris/uts/common/fs/zfs


Author: delphij
Date: Thu Jul 18 00:22:42 2013
New Revision: 253441
URL: http://svnweb.freebsd.org/changeset/base/253441

Log:
 Manually merge part of vendor import r238583 from Illumos.
Illumos changeset: 13680:2bd022a765e2
 Illumos ZFS issue:
2671 zpool import should not fail if vdev ashift has increased MFC after: 3 days

Modified:
 head/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c
 head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c

Modified: head/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c
==============================================================================
--- head/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c Wed Jul 17 23:37:33 
2013 (r253440)
+++ head/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c Thu Jul 18 00:22:42 
2013 (r253441)
@@ -3997,7 +3997,7 @@ print_dedup_stats(nvlist_t *config)

 /*
 * If the pool was faulted then we may not have been able to
- * obtain the config. Otherwise, if have anything in the dedup
+ * obtain the config. Otherwise, if we have anything in the dedup
 * table continue processing the stats.
 */
 if (nvlist_lookup_uint64_array(config, ZPOOL_CONFIG_DDT_OBJ_STATS,

Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c
==============================================================================
--- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c Wed Jul 17 
23:37:33 2013 (r253440)
+++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c Thu Jul 18 
00:22:42 2013 (r253441)
@@ -1258,12 +1258,16 @@ vdev_open(vdev_t *vd)
 vd->vdev_ashift = MAX(ashift, vd->vdev_ashift);
 } else {
 /*
- * Make sure the alignment requirement hasn't increased.
+ * Detect if the alignment requirement has increased.
+ * We don't want to make the pool unavailable, just
+ * issue a warning instead.
 */
- if (ashift > vd->vdev_top->vdev_ashift) {
- vdev_set_state(vd, B_TRUE, VDEV_STATE_CANT_OPEN,
-     VDEV_AUX_BAD_LABEL);
- return (EINVAL);
+ if (ashift > vd->vdev_top->vdev_ashift &&
+     vd->vdev_ops->vdev_op_leaf) {
+ cmn_err(CE_WARN,
+     "Disk, '%s', has a block alignment that is "
+     "larger than the pool's alignment\n",
+     vd->vdev_path);
 }
 vd->vdev_max_asize = max_asize;
 }


================================================
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 postmas...@multiplay.co.uk.

_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Reply via email to