Date: Fri, 25 Jan 2013 20:26:02 -0800 From: Michael DeMan <freebsd@deman.com> To: Peter Jeremy <peter@rulingia.com> Cc: FreeBSD Filesystems <freebsd-fs@freebsd.org> Subject: Re: RFC: Suggesting ZFS "best practices" in FreeBSD - mapping logical to physical drives Message-ID: <32F8B97D-DE8D-4876-B127-91BE6AB9A854@deman.com> In-Reply-To: <20130123085832.GJ30633@server.rulingia.com> References: <314B600D-E8E6-4300-B60F-33D5FA5A39CF@sarenet.es> <alpine.BSF.2.00.1301220759420.61512@wonkity.com> <CAOjFWZ4X8src2DQV%2B49DjKgT7pgMbR69j%2BiRAq-UoVA0Lz3xcg@mail.gmail.com> <16E9D784-D2F2-4C55-9138-907BF3957CE8@deman.com> <20130123085832.GJ30633@server.rulingia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Except that does not work when the technician just needs to know which = darn physical disk to remove/replace by looking at the front of the box? I think possibly on this thread we are discussing some major topics - = all of which would be good categories within a 'best practices' = document? #1. Best practices for design. #2. Best practices for maintenance (logical) - ZFS 'halt scrub' would = be awesome), when to scrub, etc - how to label your disks, blends into = #3... #3. Best practices for physical maintenance - i.e at the end of the day = ZFS theoretical break down if somebody can't look at the front of the = machine and figure out which disk was the bad one? Maintenance (in my definition) including the scenario where the guy = changing the disk is not necessarily a FreeBSD wizard and = all-knowledgable about gpart, gnop, glabel and such? Some idea that whoever designs, builds, deploys and then maintains the = physical server over a 3-7 year service life - that one person is = supposed to do all of that does not work well either for small = businesses or large businesses? Sorta off topic on this - sorry. On Jan 23, 2013, at 12:58 AM, Peter Jeremy <peter@rulingia.com> wrote: > On 2013-Jan-22 18:06:27 -0800, Michael DeMan <freebsd@deman.com> = wrote: >> # OAIMFD 2011.04.13 adding this to force ordering on adaX disks=20 >> # dev.mvs.0.%desc: Marvell 88SX6081 SATA controller=20 >> # dev.mvs.1.%desc: Marvell 88SX6081 SATA controller=20 >>=20 >> hint.scbus.0.at=3D"mvsch0" >> hint.ada.0.at=3D"scbus0"=20 > ... >=20 > That only works until a BIOS or OS change alters the probe order and > reverses the controller numbers. >=20 > The correct solution to the problem is gpart labels - which rely on > on-disk metadata and so don't care about changes in the path to the > disk. >=20 > --=20 > Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?32F8B97D-DE8D-4876-B127-91BE6AB9A854>