kern/167272: [zfs] ZFS Disks reordering causes ZFS to pick the
wrong drive
Anna-Maria
ichhasseesnamenauszuwaehlen at yahoo.ca
Thu Apr 26 15:50:13 UTC 2012
The following reply was made to PR kern/167272; it has been noted by GNATS.
From: Anna-Maria <ichhasseesnamenauszuwaehlen at yahoo.ca>
To: bug-followup at FreeBSD.org, david.alves at gmx.fr
Cc:
Subject: Re: kern/167272: [zfs] ZFS Disks reordering causes ZFS to pick the
wrong drive
Date: Thu, 26 Apr 2012 17:40:19 +0200
This is a multi-part message in MIME format.
--------------060700060302040105000702
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
You can use the "zdb" command to see the guid of the disk, and use that
to replace it.
eg.
children[2]:
type: 'disk'
id: 2
guid: *713716085525288922*
path: '/dev/*da21*'
phys_path: '/dev/*da21*'
whole_disk: 1
*not_present: 1*
metaslab_array: 13154506
metaslab_shift: 25
ashift: 9
asize: 4289200128
is_log: 1
DTL: 13647709
create_txg: 2302081
zpool replace 713716085525288922 da31
Also, I had a barely related problem with 8.2-RELEASE (or may have been
the 8-STABLE from April which is in an iso on the ftp site), where
rebooting would make ZFS use the wrong disk in the pool. (eg. my hot
spare might end up being part of the raidz2, and so constantly create
checksum errors until I scrub it or move it back). And then I tried
warning others about it, and they would always say that I make no sense,
and zfs uses the guid so can't get confused, etc. and only shows the
label/device on the command output. So I tried reproducing it, and it
was impossible for me to reproduce with 8-STABLE (October 2011). Your
problem isn't quite the same, but may be related.
Also in 8-STABLE, any time I do weird stuff like you did, the disk shows
the guid on the next reboot instead of the old device name, and on the
right it will add a comment saying "was da21". (but mostly I use gpt
slices, so I might just not have enough experience with that particular
problem).
So I highly recommend you try 8.3-RELEASE (or 8-STABLE).
And one more warning... if you ugrade to newer than 8.2-RELEAE, and have
an old pool from 8.2-RELEASE and upgrade it to v28, you still can't
remove logs. It is bugged. You need to destroy and recreate.
--------------060700060302040105000702
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-15">
</head>
<body bgcolor="#FFFFFF" text="#000000">
You can use the "zdb" command to see the guid of the disk, and use
that to replace it.<br>
<br>
eg. <br>
<br>
children[2]:<br>
type: 'disk'<br>
id: 2<br>
guid: <b>713716085525288922</b><br>
path: '/dev/<b>da21</b>'<br>
phys_path: '/dev/<b>da21</b>'<br>
whole_disk: 1<br>
<b>not_present: 1</b><br>
metaslab_array: 13154506<br>
metaslab_shift: 25<br>
ashift: 9<br>
asize: 4289200128<br>
is_log: 1<br>
DTL: 13647709<br>
create_txg: 2302081<br>
<br>
zpool replace 713716085525288922 da31<br>
<br>
Also, I had a barely related problem with 8.2-RELEASE (or may have
been the 8-STABLE from April which is in an iso on the ftp site),
where rebooting would make ZFS use the wrong disk in the pool. (eg.
my hot spare might end up being part of the raidz2, and so
constantly create checksum errors until I scrub it or move it back).
And then I tried warning others about it, and they would always say
that I make no sense, and zfs uses the guid so can't get confused,
etc. and only shows the label/device on the command output. So I
tried reproducing it, and it was impossible for me to reproduce with
8-STABLE (October 2011). Your problem isn't quite the same, but may
be related.<br>
<br>
Also in 8-STABLE, any time I do weird stuff like you did, the disk
shows the guid on the next reboot instead of the old device name,
and on the right it will add a comment saying "was da21". (but
mostly I use gpt slices, so I might just not have enough experience
with that particular problem).<br>
<br>
So I highly recommend you try 8.3-RELEASE (or 8-STABLE).<br>
<br>
And one more warning... if you ugrade to newer than 8.2-RELEAE, and
have an old pool from 8.2-RELEASE and upgrade it to v28, you still
can't remove logs. It is bugged. You need to destroy and recreate.<br>
</body>
</html>
--------------060700060302040105000702--
More information about the freebsd-fs
mailing list