From owner-freebsd-stable@freebsd.org Mon Nov 16 21:19:57 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5A7F4A30EA9; Mon, 16 Nov 2015 21:19:57 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 10595189B; Mon, 16 Nov 2015 21:19:57 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by obdgf3 with SMTP id gf3so133127158obd.3; Mon, 16 Nov 2015 13:19:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DbhmXduNBQvMEXo+tgkVysvcxT4EF9WC4VYxdBB5FYk=; b=YzFMQCxcuVNE6leuw7bTbw2Coni/5NaeRJTbc82XHjv48I6KLwiuzT3jnT6TspMMTG Xn8rFqSQghYDN4onDzQ58/GN69w/5fpN7aFpdedIdN1F7hIzUchVufmE6DEEyX4W6IcB cnvqqQglaiA2CexMzl/9Z6Jj0SuPlAcQQHELrYALN4c0Rs6Uj2lST48VUm7gWR6TM+Ag xT2EWjDoGs9yzwOdx2X+lmvctRCGw6iV5SKFx/CGR8zi5GLj8qJ+GE67OFrDqkRs5Hvg DtqMCvtio1cjaYpWpIBgh0xcVgBxwzXZ/5HPBvrMpOn6uN3e89biO8jX0kT9c+Ph1SPR JVFQ== MIME-Version: 1.0 X-Received: by 10.60.76.42 with SMTP id h10mr22713812oew.13.1447708796286; Mon, 16 Nov 2015 13:19:56 -0800 (PST) Received: by 10.76.29.74 with HTTP; Mon, 16 Nov 2015 13:19:55 -0800 (PST) In-Reply-To: <20151116205734.GM48728@zxy.spb.ru> References: <5644FF09.9090200@free.de> <56472686.5030301@free.de> <20151114143104.GA41119@in-addr.com> <7710CBCC-E68F-4454-9E29-E50ED1C6B511@sarenet.es> <20151116205734.GM48728@zxy.spb.ru> Date: Mon, 16 Nov 2015 13:19:55 -0800 Message-ID: Subject: Re: LSI SAS2008 mps driver preferred firmware version From: Freddie Cash To: Slawa Olhovchenkov Cc: Kevin Oberman , freebsd-scsi@freebsd.org, Royce Williams , freebsd-stable , Borja Marcos , Kai Gallasch Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 21:19:57 -0000 On Mon, Nov 16, 2015 at 12:57 PM, Slawa Olhovchenkov wrote= : > On Mon, Nov 16, 2015 at 11:40:12AM -0800, Freddie Cash wrote: > > > On Mon, Nov 16, 2015 at 11:36 AM, Kevin Oberman > wrote: > > > As already mentioned, unless you are using zfs, use gpart to label yo= u > file > > > systems/disks. Then use the /dev/gpt/LABEL as the mount device in > fstab. > > > > > > > =E2=80=8BEven if you are using ZFS, labelling the drives with the locat= ion of the > > disk in the system (enclosure, column, row, whatever) makes things so > much > > easier to work with when there are disk-related issues. > > > > Just create a single partition that covers the whole disk, label it, an= d > > use the label to create the vdevs in the pool.=E2=80=8B > > Bad idea. > Re-placed disk in different bay don't relabel automaticly. > =E2=80=8BDid the original disk get labelled automatically? No, you had to = do that when you first started using it. So, why would you expect a replaced disk to get labelled automatically? Offline the dead/dying disk. Physically remove the disk. Insert the new disk. Partition / label the new disk. "zfs replace" using the new label to get it into the pool.=E2=80=8B > Other issuse where disk placed in bay some remotely hands in data > center -- I am relay don't know how disk distributed by bays. > =E2=80=8BYou label the disks as they are added to the system the first time= . That way, you always know where each disk is located, and you only deal with the labels. Then, when you need to replace a disk (or ask someone in a remote location to replace it) it's a simple matter: the label on the disk itself tells you where the disk is physically located. And it doesn't change if the controller decides to change the direction it enumerates devices. Which is easier to tell someone in a remote location: Replace disk enc0a6 (meaning enclosure 0, column A, row 6)? or Replace the disk called da36?=E2=80=8B =E2=80=8Bor Find the disk with serial number XXXXXXXX? or Replace the disk where the light is (hopefully) flashing (but I can't tell you which enclosure, front or back, or anything else like that)? The first one lets you know exactly where the disk is located physically. The second one just tells you the name of the device as determined by the OS, but doesn't tell you anything about where it is located. And it can change with a kernel update, driver update, or firmware update! The third requires you to pull every disk in turn to read the serial number off the drive itself. In order for the second or third option to work, you'd have to write down the device names and/or serial numbers and stick that onto the drive bay itself.=E2=80=8B > Best way for identify disk -- uses enclouse services. > =E2=80=8BOnly if your enclosure services are actually working (or even enab= led). I've yet to work on a box where that actually works (we custom-build our storage boxes using OTS hardware). Best way, IMO, is to use the physical location of the device as the actual device name itself. That way, there's never any ambiguity at the physical layer, the driver layer, the OS layer, or the ZFS pool layer.=E2=80=8B > I have many sites with ZFS on whole disk and some sites with ZFS on > GPT partition. ZFS on GPT more heavy for administration. > =E2=80=8BIt's 1 extra step: partition the drive, supplying the location of= the drive as the label for the partition. Everything else works exactly the same. I used to do everything with whole drives and no labels. Did that for about a month, until 2 separate drives on separate controllers died (in a 24-bay setup) and I couldn't figure out where they were located as a BIOS upgrade changed which controller loaded first. And then I had to work on a server that someone else configured with direct-attach bays (24 cables) that were connected almost at random. Then I used glabel(8) to label the entire disk, and things were much better. But that didn't always play well with 4K drives, and replacing drives that were the same size didn't always work as the number of sectors in each disk was different (ZFS plays better with this now). Then I started to GPT partition things, and life has been so much simpler. All the partitions are aligned to 1 MB, and I can manually set the size of the partition to work around different physical sector counts. All the partitions are labelled using the physical location of the disk (originally just row/column naming like a spreadsheet, but now I'm adding enclosure name as well as we expand to multiple enclosures per system). It's so much simpler now, ESPECIALLY when I have to get someone to do something remotely. :) =E2=80=8BEveryone has their own way to manage things. I just haven't seen = any better setup than labelling the drives themselves using their physical location.=E2=80=8B --=20 Freddie Cash fjwcash@gmail.com