From owner-freebsd-fs@FreeBSD.ORG Mon Nov 17 12:57:27 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5B36A8 for ; Mon, 17 Nov 2014 12:57:27 +0000 (UTC) Received: from mail1.postbank.bg (mx.postbank.bg [195.242.126.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.postbank.bg", Issuer "GeoTrust DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D2F1A0 for ; Mon, 17 Nov 2014 12:57:25 +0000 (UTC) X-AuditID: ac100165-f791c6d000000c67-d2-5469ed23a2ea Received: from sofdc01excv16.postbank.bg ( [10.1.129.39]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail1.postbank.bg (Eurobank AD BG Outbound mail system) with SMTP id BC.FA.03175.32DE9645; Mon, 17 Nov 2014 14:42:11 +0200 (EET) From: "Ivailo A. Tanusheff" To: "freebsd-fs@freebsd.org" Subject: ZFS and glabel Thread-Topic: ZFS and glabel Thread-Index: AdACY7LrZviKSHcMQ1qsE5/tkf/bpg== Date: Mon, 17 Nov 2014 12:42:09 +0000 Message-ID: <1422065A4E115F409E22C1EC9EDAFBA4220D0DB7@sofdc01exc02.postbank.bg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.26] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLKsWRmVeSWpSXmKPExsXCxdiorqv8NjPE4PA8WYtjj3+yOTB6zPg0 nyWAMaqB0SYxLy+/JLEkVSEltTjZVik6IL+4JCkxLztWwSWzODknMTM3tUhJITPFVslYSaEg JzE5NTc1r8RWKbGgIDUvRcmOSwED2ACVZeYppOYl56dk5qXbKnkG++taWJha6hoq2SFMtVJT NjRO+M+eMetUD2vBT5GKtxuuszQwHuDvYuTgkBAwkXi81LmLkRPIFJO4cG89G4gtJDCHSWLG FCkQmw2oZNvcPUwgtoiAqcSvfwvAaoQFxCUuzrrABhGXkXi1dzYrhK0n0fBzFVg9i4CqxNL1 s8DivAL+El82PgSrZwTa9f3UGrAaZqA5t57MZ4K4QUBiyZ7zzBC2qMTLx/9YIWxZiUffHkPV 60gs2P2JDcLWlli28DUzxHxBiZMzn7BMYBSahWTsLCQts5C0zELSsoCRZRWjZHF+WkqygWGw r3uZgaFeATSC9JLSNzEC43eNAGPqDsYXV5wOMQpwMCrx8O7IzgwRYk0sK67MPcQowcGsJMIb cxEoxJuSWFmVWpQfX1Sak1p8iHE/IzAYJjJLiSbnA5NLXkm8oYmBiYmZpamphbGZBfWFDU1N jAwtDMwsTEkTVhLntV4EdL9AOjCZZqemFqQWwbzAxMEp1cAYv73sosilg57hLxtn8iya/7Aw p1lk1sc8nVenu/3mCdZ/vzOTvTM3//za1t87r+gqFvcy2W19/aV+s8ZK7/5SdYVf02NVk/4+ tVjMWnszWFhdvL07Zd287CbPENW9Hm438jdMnvxwQfz3rsDlOaGLWNxupTzceaNV4JtJ74+q 2siNjHY2saxKLMUZiYZazEXFiQDdQF64gAMAAA== X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 12:57:28 -0000 Dear all, I run to an interesting issue and I would like to discuss it with all of you= . The whole thing began with me trying to identify available HDD to include in= a zfs pool through a script/program. I assumed that the easiest way of doing this is using glabel. For example: root@FreeBSD:~ # glabel status Name Status Components gptid/248e758c-e267-11e3-95bb-08002796202b N/A ada0p1 diskid/DISK-VBdd471206-91164057 N/A ada5 diskid/DISK-VBe98b5e75-0d8cf6dc N/A ada8 diskid/DISK-VB7d006584-01beca12 N/A ada6 diskid/DISK-VB721029c3-66a60156 N/A ada7 diskid/DISK-VB31481dbb-639540a1 N/A ada2 diskid/DISK-VB95921208-4eb19f41 N/A ada4 So far it is OK and if I create pool like zpool create xxx ada4 then the lin= e for ada4 will disappear from the glabel status. As far as I remember though it is not recommended to use production pools ba= sed on the device naming, so I wanted to switch to gpt lable, i.e. diskid/D= ISK-VB95921208-4eb19f41. When I recreate pool like: zpool create xxx diskid/DISK-VB95921208-4eb19f41 the pool is cr= eated without problems, but the device does not disappear from the glabel st= atus list, thus making my program running wrong. Is this a problem with the zfs implementation, my server or the general idea= is wrong? BTW, if I label the disk additionally, like: glabel create VB95921208-4eb19f41 ada4 zpool create xxx label/VB95921208-4eb19f41 The glabel status again shows the right information. The problem with the la= test approach is that if someone executes: glabel destroy -f VB95921208-4eb19f41 The result becomes: pool: xxx state: UNAVAIL status: One or more devices are faulted in response to IO failures. action: Make sure the affected devices are connected, then run 'zpool clear'= . see: http://illumos.org/msg/ZFS-8000-HC scan: none requested config: NAME STATE READ WRITE CKSUM xxx UNAVAIL 0 0 0 6968348230421469155 REMOVED 0 0 0 was /dev/label/VB= 95921208-4eb19f41 And the data is practically unrecoverable. So my questions are: - Is there a way to make glabel to show the right data when I use diskid/DIS= K-VB95921208-4eb19f41 - Which is the most proper way of creating vdevs - with disk name (ada4), di= skid (diskid/DISK-VB95921208-4eb19f41) or manual labeling? - How may I found which disks are free, if the diskid approach is the best s= olution? Regards, Ivailo Tanusheff Disclaimer: This communication is confidential. If you are not the intended recipient, y= ou are hereby notified that any disclosure, copying, distribution or taking= any action in reliance on the contents of this information is strictly proh= ibited and may be unlawful. If you have received this communication by mista= ke, please notify us immediately by responding to this email and then delete= it from your system. Eurobank Bulgaria AD is not responsible for, nor endorses, any opinion, reco= mmendation, conclusion, solicitation, offer or agreement or any information= contained in this communication. Eurobank Bulgaria AD cannot accept any responsibility for the accuracy or co= mpleteness of this message as it has been transmitted over a public network.= If you suspect that the message may have been intercepted or amended, pleas= e call the sender.