Date: Tue, 22 Jan 2013 18:06:27 -0800 From: Michael DeMan <freebsd@deman.com> To: Freddie Cash <fjwcash@gmail.com> Cc: FreeBSD Filesystems <freebsd-fs@freebsd.org>, Scott Long <scottl@samsco.org> Subject: Re: RFC: Suggesting ZFS "best practices" in FreeBSD - mapping logical to physical drives Message-ID: <16E9D784-D2F2-4C55-9138-907BF3957CE8@deman.com> In-Reply-To: <CAOjFWZ4X8src2DQV%2B49DjKgT7pgMbR69j%2BiRAq-UoVA0Lz3xcg@mail.gmail.com> References: <314B600D-E8E6-4300-B60F-33D5FA5A39CF@sarenet.es> <alpine.BSF.2.00.1301220759420.61512@wonkity.com> <CAOjFWZ4X8src2DQV%2B49DjKgT7pgMbR69j%2BiRAq-UoVA0Lz3xcg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, We have been able to effectively mitigate this (and rigorously tested) problem. I myself am fussy and in the situation where a disk drive dies want to make sure that the data-center technician is removing/replacing exactly the correct disk. -AND- if the machine reboots with a disk removed, or added - that it all just looks normal. I think this is basically another item that there are standard ways to deal with it but there is no documentation? What we did was /boot/device.hints. On the machine we rigorously tested this on, we have in /boot/device.hints. This is for the particular controllers as noted but I think works for any SATA or SAS controllers? # OAIMFD 2011.04.13 adding this to force ordering on adaX disks # dev.mvs.0.%desc: Marvell 88SX6081 SATA controller # dev.mvs.1.%desc: Marvell 88SX6081 SATA controller hint.scbus.0.at="mvsch0" hint.ada.0.at="scbus0" hint.scbus.1.at="mvsch1" hint.ada.1.at="scbus1" hint.scbus.2.at="mvsch2" hint.ada.2.at="scbus2" hint.scbus.3.at="mvsch3" hint.ada.3.at="scbus3" ...and so on up to ada14... Inserting disks that were empty before and rebooting, or removing disks that did exist and rebooting - it all 'just works'. On Jan 22, 2013, at 3:02 PM, Freddie Cash <fjwcash@gmail.com> wrote: > On Jan 22, 2013 7:04 AM, "Warren Block" <wblock@wonkity.com> wrote: >> >> On Tue, 22 Jan 2013, Borja Marcos wrote: >> >>> 1- Dynamic disk naming -> We should use static naming (GPT labels, for > instance) >>> >>> ZFS was born in a system with static device naming (Solaris). When you > plug a disk it gets a fixed name. As far as I know, at least from my > experience with Sun boxes, c1t3d12 is always c1t3d12. FreeBSD's dynamic > naming can be very problematic. >>> >>> For example, imagine that I have 16 disks, da0 to da15. One of them, > say, da5, dies. When I reboot the machine, all the devices from da6 to da15 > will be renamed to the device number -1. Potential for trouble as a minimum. >>> >>> After several different installations, I am preferring to rely on static > naming. Doing it with some care can really help to make pools portable from > one system to another. I create a GPT partition in each drive, and Iabel it > with a readable name. Thus, imagine I label each big partition (which takes > the whole available space) as pool-vdev-disk, for example, > pool-raidz1-disk1. >> >> >> I'm a proponent of using various types of labels, but my impression after > a recent experience was that ZFS metadata was enough to identify the drives > even if they were moved around. That is, ZFS bare metadata on a drive with > no other partitioning or labels. >> >> Is that incorrect? > > The ZFS metadata on disk allows you to move disks around in a system and > still import the pool, correct. > > But the ZFS metadata will not help you figure out which disk, in which bay, > of which drive shelf just died and needs to be replaced. > > That's where glabels, gpt labels, and similar come in handy. It's for the > sysadmin, not the system itself. > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16E9D784-D2F2-4C55-9138-907BF3957CE8>