RFC: Suggesting ZFS "best practices" in FreeBSD - mapping logical to physical drives

[Michael DeMan]

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 at gmail.com> wrote:

> On Jan 22, 2013 7:04 AM, "Warren Block" <wblock at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"