Date: Thu, 29 Mar 2012 21:23:14 -0600 (MDT) From: Warren Block <wblock@wonkity.com> To: Daniel Gerzo <danger@freebsd.org> Cc: freebsd-doc@freebsd.org, pjd@freebsd.org Subject: Re: Handbook RAID1 example Message-ID: <alpine.BSF.2.00.1203290955380.51317@wonkity.com> In-Reply-To: <alpine.BSF.2.00.1203272317290.41849@wonkity.com> References: <alpine.BSF.2.00.1201231536490.92721@wonkity.com> <20120125.111625.2289296443525755896.hrs@allbsd.org> <7e043215e6cd0f2da324d6599c921fec@rulez.sk> <alpine.BSF.2.00.1203272317290.41849@wonkity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 27 Mar 2012, Warren Block wrote: > Procedure tested on both 9.0-RELEASE and 8.2-RELEASE. It could stand more > testing. HTML: http://www.wonkity.com/~wblock/gmirror/geom-mirror.html And more testing does show a problem. My tests were all using the smaller drive as the new drive (20G). Create a mirror using that whole drive, copy the data from the 20G allocated space on the original 200G drive. But it doesn't work the other way around. Create a mirror of the full larger drive, and the smaller drive cannot be inserted into it; it can't mirror a 200G drive. The procedure really ought to work with different-sized drives, because that situation is expectable. Telling the users that the disks must be identical is weak. It may still fail because of the presence or absence of a label or other metadata eating one or more sectors even if the drives are identical. Now I'm considering labeling each disk, then using gnop(8) to create a matching-sized device on each. This adds more complexity, and maybe the thing to do is put the whole thing into a shell script. Suggestions welcome.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1203290955380.51317>