From owner-freebsd-questions@freebsd.org Thu Sep 29 02:25:08 2016 Return-Path: Delivered-To: freebsd-questions@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 A80BAC0129B for ; Thu, 29 Sep 2016 02:25:08 +0000 (UTC) (envelope-from vas@mpeks.tomsk.su) Received: from relay2.tomsk.ru (mail.sibptus.tomsk.ru [212.73.124.5]) by mx1.freebsd.org (Postfix) with ESMTP id D725BBD8 for ; Thu, 29 Sep 2016 02:25:07 +0000 (UTC) (envelope-from vas@mpeks.tomsk.su) X-Virus-Scanned: by clamd daemon 0.98.5_1 for FreeBSD at relay2.tomsk.ru Received: from [212.73.125.240] (HELO admin.sibptus.transneft.ru) by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.16) with ESMTPS id 39364076; Thu, 29 Sep 2016 08:24:45 +0600 Received: from admin.sibptus.transneft.ru (sudakov@localhost [127.0.0.1]) by admin.sibptus.transneft.ru (8.14.9/8.14.9) with ESMTP id u8T2P4bq034928; Thu, 29 Sep 2016 09:25:04 +0700 (KRAT) (envelope-from vas@mpeks.tomsk.su) Received: (from sudakov@localhost) by admin.sibptus.transneft.ru (8.14.9/8.14.9/Submit) id u8T2P1w6034924; Thu, 29 Sep 2016 09:25:01 +0700 (KRAT) (envelope-from vas@mpeks.tomsk.su) X-Authentication-Warning: admin.sibptus.transneft.ru: sudakov set sender to vas@mpeks.tomsk.su using -f Date: Thu, 29 Sep 2016 09:25:01 +0700 From: Victor Sudakov To: "Brandon J. Wandersee" Cc: Michael Schuster , freeBSD Mailing List , Mike Tancsa Subject: Re: complete clone/restore from a ZFS-based system replication stream Message-ID: <20160929022501.GA33088@admin.sibptus.transneft.ru> References: <20160926154720.GA75556@admin.sibptus.transneft.ru> <688eec35-bc7b-ae05-b765-106933b522d1@sentex.net> <20160928145137.GA27497@admin.sibptus.transneft.ru> <20160928154941.GB27823@admin.sibptus.transneft.ru> <0f4490dc-34e3-3caa-7aa7-a2a284ed0ffd@sentex.net> <20160928164601.GA28493@admin.sibptus.transneft.ru> <868tub1om1.fsf@WorkBox.Home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <868tub1om1.fsf@WorkBox.Home> Organization: AO "Svyaztransneft", SibPTUS X-PGP-Key: http://www.dreamwidth.org/pubkey?user=victor_sudakov X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 02:25:08 -0000 Brandon J. Wandersee wrote: > > >> the FreeBSD Mastery: ZFS books (for example) explain how to avoid this > >> issue too. > > > > Namely? Or should I buy the book? > > > > Of course, I can do with glabel or something, but it's a pity > > bsdinstall creates an unclonable configuration. > > It's not a bsdinstall problem. To some extent, it is. For example Linux installers use labels, not physical device nodes, from the very start. > It's really only a problem at all if > particular circumstances arise---like if you move a disk from a one-disk > system to another, multi-disk system. Device nodes are assigned based > either on the order in which the motherboard firmware detects and > initializes the devices, or the ports into which the devices are > plugged. Which one gets used depends on your motherboard, and if it's > the former, nobody has any control over it. Your backup-and-restoration > plan needs to take that into account. The problem I speak about is more subtle than minor device numbers changing. It's device nodes actually disappearing. I'll explain below. > > That's why partition/filesystem labels were invented in the first > place. It's why a Windows disk can be transplanted into any slot on any > machine, and it can boot without intervention from the user---the > filesystems are all labeled. The worst problems of the kind were on Solaris, where I had to regenerate /etc/path_to_inst, /dev/devices and a lot of other non-obvious things after simply moving a disk or controller. That was before ZFS, however. But I digress. > > Since swap was the example you brought up I'm guessing that's your chief > concern, since a ZFS pool is usually unaffected by a change in drive > letters. In that case, just modify /etc/fstab before rebooting or > transplanting the disk. No, modifying /etc/fstab like this won't do much good. Please try to read me. 1. You attach a second disk, it becomes ada1. You create ada1p2 for swap and ada1p3 for zfs. 2. You create a zpool on ada1p3. "zpool status" shows ada1p3 as the physical device. 3. You move the disk to another system. It boots, and being unable to find ada1p3, loader(?) becomes desperate and uses /dev/diskid/BLA-BLA-BLAp3 as the physical device for the root pool. 4. Once the diskid label is in use, there is no more ada1p3 or ada0p3 or whatever. It gets hidden. 5. You curse aloud and use /dev/diskid/BLA-BLA-BLAp2 for swap because no device nodes and no other labels are available and there is no way to make them visible or create more human-friendly labels for partitions. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru